From: Andrew E S. <and...@gm...> - 2012-09-26 21:36:33
|
Is there a reason that when using the System::project_solution command with a FunctionBase object that the time variable is always set to zero? It occurs on Line 490 of system_projection.C. If there is a reason, why is the time variable included at all? It seems to me that this should be changed to the system.time variable. -- Andrew E. Slaughter, PhD and...@gm... Materials Process Design and Control Laboratory Sibley School of Mechanical and Aerospace Engineering 169 Frank H. T. Rhodes Hall Cornell University Ithaca, NY 14853-3801 (607) 229-1829 http://aeslaughter.github.com/ |
From: Roy S. <roy...@ic...> - 2012-09-26 22:27:01
|
On Wed, 26 Sep 2012, Andrew E Slaughter wrote: > Is there a reason that when using the System::project_solution command with > a FunctionBase object that the time variable is always set to zero? It > occurs on Line 490 of system_projection.C. If there is a reason, why is the > time variable included at all? It seems to me that this should be changed > to the system.time variable. The original System::project_* APIs took pointer-to-function data with a function signature that didn't accept a time argument; when updating the API to allow more general functors I simply didn't make full use of that generality. line 490 (and a few dozen other lines with the same problem) should be fixed as of svn r6118; please give that a try. Thanks, --- Roy |
From: Roy S. <roy...@ic...> - 2012-09-26 22:31:39
|
On Wed, 26 Sep 2012, Roy Stogner wrote: > fixed as of svn r6118; please give that a try. Make that r6119, for obvious and embarrassing reasons... --- Roy |
From: Roy S. <roy...@ic...> - 2012-09-27 03:58:17
|
On Wed, 26 Sep 2012, Andrew E Slaughter wrote: > Thanks for the help. I am trying to build the latest svn build (r6119) but get the following error, has anyone received this before? I was > previously using 0.7.3.1 which compiles and runs fine on my system. I used the following command for configuration: ./configure --disable-slepc > --with-vtk-include=$VTK_INCLUDE_DIR. > --- Building Metis --------------------------- > make[2]: Entering directory `/home/slaughter/packages/libmesh/contrib/metis/GKlib' > make[2]: Nothing to be done for `all'. > make[2]: Leaving directory `/home/slaughter/packages/libmesh/contrib/metis/GKlib' > make[2]: Entering directory `/home/slaughter/packages/libmesh/contrib/metis/Lib' > Compiling C (in optimized mode) balance.c... > balance.c: In function ‘libmetis__Bnd2WayBalance’: > balance.c:50:3: error: ‘WCOREPUSH’ undeclared (first use in this function) > balance.c:50:3: note: each undeclared identifier is reported only once for each function it appears in That undeclared symbol should be a macro defined in macros.h, included into balance.c via metislib.h. Any of which might have changed in between libMesh 0.7.3.1 and the current svn; we upgraded our copy of METIS to the latest available a few months ago. Is it possible you've got another macros.h file or metislib.h file installed in a system include directory and your compiler is finding the undesired one first? If so then uninstalling the conflicting package might be a reasonable workaround. Either that or you could configure libMesh with METIS and ParMETIS disabled and see if our space-filling-curve-partitioner-that-nobody-uses capability is still in working order... Regardless, we should probably make it harder for such a problem to come up. We just added an option to force libMesh headers to be included as "libmesh/whatever.h" to avoid exactly those sorts of conflicts, but there's currently nothing preventing header naming conflicts from affecting some of the third-party packages in our contrib/ directory. Copying this to libmesh-devel in case anyone has other ideas; I hate to have any significant "fork" between our copies of contrib/ libraries and the upstream sources, and changing all their #include directives might qualify as significant. --- Roy |
From: Roy S. <roy...@ic...> - 2012-09-27 21:46:18
|
On Thu, 27 Sep 2012, Andrew E Slaughter wrote: > I am not using Make.common so I don't have anything defined for > "make echo". I built my own Cmake based make system, which worked > great with 0.7.3.1. That would be the problem, then. We haven't actually committed any patches to your Cmake files. ;-) Adding the -I$LIBMESH_DIR/include to your own include flags will probably fix the problem. --- Roy |