Furthermore,
Finally I also found the real reason of the crash in the first email.
It is my own fault: the last variable, lambda, as the Lagrange multiplier is
also required with a branch in init_value(). Since there is a call to
a function pointer to lambda, definitely there is an error.
This
Dear John,
Thank you for your kind help.
At least I got one way, just as a temporary solution:
I set a global string outside everything, namely, std::string project_var, then
in the function
Number init_value (const Point& p,
const Parameters& parameters,
co
On Mon, Apr 20, 2015 at 11:32 AM, Zhenyu Zhang wrote:
> Here I tried to add an if block in init_value(),
> if (boost::iequals(varname, string("p")))
> {
> ... // calculate the return value like before
> }
>
> Then the setting of initial values worked.
>
> Since the above code only work for one va
PM
To: "Zhenyu Zhang";
Cc: "libmesh-users";
Subject: Re: [Libmesh-users] segmentation fault after projection solution
On Mon, Apr 20, 2015 at 8:04 AM, grandrabbit wrote:
Hello,
I wrote a class for set up initial values and called it by
system.attach_in
nal --
From: "John Peterson";;
Send time: Monday, Apr 20, 2015 10:37 PM
To: "grandrabbit";
Cc: "libmesh-users";
Subject: Re: [Libmesh-users] segmentation fault after projection solution
On Mon, Apr 20, 2015 at 8:04 AM, grandrabbit wrote:
Hel
On Mon, Apr 20, 2015 at 8:04 AM, grandrabbit wrote:
> Hello,
>
> I wrote a class for set up initial values and called it by
> system.attach_init_function (init_sys);
>
> Here is the part of init_sys
>
> void init_sys(EquationSystems& es,const std::string& system_name)
> {
> Syst
Hello,
I wrote a class for set up initial values and called it by
system.attach_init_function (init_sys);
Here is the part of init_sys
void init_sys(EquationSystems& es,const std::string& system_name)
{
System & system =
es.get_system(system_name);
vector< string >
On Wed, Feb 18, 2015 at 7:49 AM, wrote:
> Hello,
>
> I was finally able to get my hands on PGI's debugger. It seems like the
> following error that occurs when running example-opt in miscellaneous_ex8
>
> is caused by the Eigen library. The PGI debugger pgdbg prints this:
>
> pgdbg> Error digesti
Hello,
I was finally able to get my hands on PGI's debugger. It seems like the
following error that occurs when running example-opt in miscellaneous_ex8
***
* Running Example miscellaneous_ex8:
* example-opt
**
Forget it, I found out (it was the mesh generation the problem...)
Thanks anyway
On Thu, Oct 9, 2014 at 11:33 AM, Rodrigo Broggi wrote:
> Hi!
>
> I am having problems in running time with this non-linear system that I am
> trying to solve. The message that comes out is the following:
>
> Stack
Hi!
I am having problems in running time with this non-linear system that I am
trying to solve. The message that comes out is the following:
Stack frames: 1
0: 0 libmesh_opt.0.dylib 0x00010c935ce6
libMesh::print_trace(std::ostream&) + 38
[0] ../src/fe/fe_lagrange.C, line 62
Hi, I get the following error while trying to add an initialize function to a
transientnonlinearImplicitsystem . Here is the code that I have .
_equation_system= new EquationSystems(mesh);
TransientNonlinearImplicitSystem & system =
_equation_system->add_system ("ch");
system.
you should select carefully what type of warnings to disable in this way.
in my example i turned off warnings only for unused variables and
parameters that in general should not pose any serious threat to your
code (in fact i cannot imagine an example in which such approach would
fail, do you have
On Wed, 1 Jun 2011, Derek Gaston wrote:
> Very cool do we need something like a
> LIBMESH_INCLUDE_NO_WARN_BEGIN and LIBMESH_INCLUDE_NO_WARN_END that
> could be set to compiler specific #pragmas at configure time?
That sounds like a pretty nice idea. Even after going so far as to
edit my loc
Very cool do we need something like a LIBMESH_INCLUDE_NO_WARN_BEGIN and
LIBMESH_INCLUDE_NO_WARN_END that could be set to compiler specific #pragmas at
configure time?
Derek
On Jun 1, 2011, at 8:11 AM, Antonio Cervone wrote:
> you can specity to gcc that warnings coming from outside library
you can specity to gcc that warnings coming from outside library
should be ignored wrapping the include in a pragma
// Tell the compiler to ignore specific kind of warnings:
#pragma GCC diagnostic ignored "-Wunused-variable"
#pragma GCC diagnostic ignored "-Wunused-parameter"
#include
// Restor
On Tue, 31 May 2011, Kyunghoon Lee wrote:
/opt/local/include/mpicxx.h:386: warning: unused parameter ‘oldtype’
/opt/local/include/mpicxx.h:386: warning: unused parameter ‘keyval’
/opt/local/include/mpicxx.h:386: warning: unused parameter ‘ex’
/opt/local/include/mpicxx.h:386: warning: unused par
>> On Tue, May 31, 2011 at 1:08 PM, Kyunghoon Lee wrote:
>>> Hello,
>>>
>>> I'm trying to install libmesh on a MacOS X 10.6.7, which has a gcc-4.2
>>> compiler from Xcode 3.2.6. I had no trouble with compiling libmesh, but I
>>> got a seg fault error for the examples.
>>>
>>> First, I source
To avoid this... if you are not needing to compile any fortran then you can
just use the MPI that comes with OSX (OpenMP). Just set CC, CXX, etc to mpicc,
mpicxx etc for both PetsC and libMesh... and don't tell PetsC to download mpich.
Note that we don't typically work this way. We usually dow
On Tue, May 31, 2011 at 1:08 PM, Kyunghoon Lee wrote:
> Hello,
>
> I'm trying to install libmesh on a MacOS X 10.6.7, which has a gcc-4.2
> compiler from Xcode 3.2.6. I had no trouble with compiling libmesh, but I
> got a seg fault error for the examples.
>
> First, I source-compiled petsc with
Hello,
I'm trying to install libmesh on a MacOS X 10.6.7, which has a gcc-4.2 compiler
from Xcode 3.2.6. I had no trouble with compiling libmesh, but I got a seg
fault error for the examples.
First, I source-compiled petsc with the following configuration option:
export PETSC_DIR=$PWD
./conf
Hi Roy:
Yes. The problem apparently was not inside the clear as it should have
thrown a SIGABRT. The problem was in the call
_boundary_node_id.clear() because _boundary_node_id was cleared from
the stack inside the constructor for Mesh. This was because Libmesh
was compiled with the _GLIBCXX_DEBUG
On Tue, 15 Dec 2009, Rahul Sampath wrote:
> In the following example code:
>
> Mesh * mesh = new Mesh(3);
> delete mesh;
>
> The destructor of mesh is called, which through a bunch of nested
> calls to parent destructors ends up calling BoundaryInfo::clear().
> This calls
> _boundary_node_id.cle
On Tue, 15 Dec 2009, Rahul Sampath wrote:
> According to GCC 4.3.2, clearing an empty container is not safe:
Interesting. Apparently someone noticed this flaw in the C++ standard
in 1999, but it wasn't officially fixed in the standard until 2003:
http://www.open-std.org/jtc1/sc22/wg21/docs/lwg
Hi:
I just wanted to bring this to your attention:
In the following example code:
Mesh * mesh = new Mesh(3);
delete mesh;
The destructor of mesh is called, which through a bunch of nested
calls to parent destructors ends up calling BoundaryInfo::clear().
This calls
_boundary_node_id.clear(). In
25 matches
Mail list logo
