On Fri, Sep 20, 2013 at 10:26 PM, Paul T. Bauman wrote:
>
> Thanks for the test case! I'll play with this in a little while and see if
> I can reproduce.
>
OK, I can reproduce. Will figure out the problem and get a PR in. You said
this worked previously - any chance you have a hash or version nu
Hi Manav,
On Fri, Sep 20, 2013 at 10:22 PM, Manav Bhatia wrote:
>Did you try this in 2D or 3D?
>
2D
> I do not get this error in 2D, but it shows up in 3D.
>
Hmm, OK.
>
>The following code is able to reproduce the issue at my end.
>
> int main (int argc, char* const argv[])
> {
>
Hi Paul,
Did you try this in 2D or 3D? I do not get this error in 2D, but it shows up
in 3D.
The following code is able to reproduce the issue at my end.
int main (int argc, char* const argv[])
{
// Initialize libMesh.
LibMeshInit init (argc, argv);
{
ParallelMe
Yes, it is 2239. I am sorry about the typo and the resulting confusion.
-Manav
On Fri, Sep 20, 2013 at 4:07 PM, Roy Stogner wrote:
>
> On Fri, 20 Sep 2013, Manav Bhatia wrote:
>
> Sorry I was not too specific. I am on the git master, and line 2339 is a
>> call to qsiderule.n_points(). It has an
Hmm. I can't reproduce this. I have a code that uses FEMFunction for
projections and I bumped up the basis order and cannot trip the error you
are. In fact, I manually verified that n_points() returns the correct value
on that line. Can you make a test case that trips the error? Are you using
a LAG
Just found the the call to side_fe_reinit() in this for loop. It seems like
the entire block from lines 2238 to 2247 should be moved to after the
context.side_fe_reinit() ?
-Manav
On Fri, Sep 20, 2013 at 4:21 PM, Manav Bhatia wrote:
> I was comparing the code with AssemblyContributions in fem_s
I was comparing the code with AssemblyContributions in fem_system.C, and
see that context.side_fe_reinit() has not been called before the call to
get qsiderule.n_points(). Should that be added to the for loop on element
sides at line 2248 and move the get_side_qrule method call (line
2238) after t
On Fri, 20 Sep 2013, Manav Bhatia wrote:
> Sorry I was not too specific. I am on the git master, and line 2339 is a
> call to qsiderule.n_points(). It has an assertion of
> libmesh_assert(!_points.empyt()), where the code throws an exception.
I think Paul's (and my) confusion was a simple typo -
On Fri, 20 Sep 2013, Manav Bhatia wrote:
> I tried to dig into this and identified that this is due to the
> destructor being called after MPI_finalize() (libmesh.C: line 625). The
> following code is able to repreduce the problem at my end:
>
> MPI_Init(&argc, const_cast(&argv));
> std::auto_
Hi,
Have there been any changes to System::project_solution() with
FEMFunctionBase over the last 2-3 months?
I had a piece of code that was working fine with it, but now is throwing
an error at line 2339 in sytem_projection.C:
const unsigned int n_qp = qsiderule.n_points();
It seems
On Fri, Sep 20, 2013 at 2:45 PM, Paul T. Bauman wrote:
> On Fri, Sep 20, 2013 at 1:34 PM, Manav Bhatia wrote:
>
>>
>>Have there been any changes to System::project_solution() with
>> FEMFunctionBase over the last 2-3 months?
>>
>
> Current master shows FEMFunctionBase was touched 5 months ag
Hi Roy,
I got this to work at my end. I pretty much moved the MPI_Finalize block
(inside ~LibMeshInit() ) to the end of the destructor, and commented out
the line
if (libMesh::on_command_line ("--redirect-stdout"))
so that the perflog is purged before MPI_Finalize(). (Any reason to keep
thi
Another datapoint, I see a random failure under Linux with gcc using
openmpi-1.7.2 that disappears with 1.6.?, so be careful out there. I'm trying
to whittle it down but haven't been able to make much progress yet.
I wish macports let you subscribe to a 'stable' tree!
On Sep 20, 2013, at 1:3
On Fri, Sep 20, 2013 at 1:34 PM, Manav Bhatia wrote:
>
>Have there been any changes to System::project_solution() with
> FEMFunctionBase over the last 2-3 months?
>
Current master shows FEMFunctionBase was touched 5 months ago.
>I had a piece of code that was working fine with it, but
Hi,
Sometime ago I had sent an email concerning a runtime error I was seeing
upon termination of my code. This was happening inside call to the
destructor of libMesh::perflog, leading to a memory error while calling
localtime() at line 46 of timestamp.C.
I tried to dig into this and identif
15 matches
Mail list logo
