Add System::project_solution/System::project_vector methods utilizing FEMFunctionBase functors #21
Conversation
|
libMesh - C++ Finite Element Library » libmesh #91 SUCCESS |
| @@ -1711,6 +1819,627 @@ void ProjectSolution::operator()(const ConstElemRange &range) const | |||
| } | |||
|
|
|||
|
|
|||
| void ProjectFEMSolution::operator()(const ConstElemRange &range) const | |||
There was a problem hiding this comment.
This in particular looks like a lot of code duplication - can we do something clever with templates instead??
Similarly with the ProjectFEMSolution vs ProjectSolution classes - could their common functionality be in a base class or templated class?
There was a problem hiding this comment.
On Fri, Dec 21, 2012 at 7:16 AM, Benjamin S. Kirk
notifications@github.comwrote:
This in particular looks like a lot of code duplication - can we do
something clever with templates instead??Similarly with the ProjectFEMSolution vs ProjectSolution classes - could
their common functionality be in a base class or templated class?It is quite a bit of code duplication. I'm not sure templating will work in
teh ProjectFEMSolution case because the algorithm is slightly different
because of the construction of the FEMContext object (in particular, the
element and variable loop order is switched to avoid superfluous element
reiniting). Nevertheless, I'll look into trying to remove some of the code
duplication.
However, at a higher level, I've been silently wondering whether we can
encapsulate these element-local solves better because very similar
algorithms appear in adaptivity, Dirichlet constraints, periodic
constraints, etc. In particular, HCURL/HDIV continuity has been on my TODO
list for awhile and part of that was figuring out all the different places
that would have to be put in. Would be nice to only have to do it once.
There was a problem hiding this comment.
On Fri, 21 Dec 2012, Paul T. Bauman wrote:
I'm not sure templating will work in teh ProjectFEMSolution case
because the algorithm is slightly different because of the
construction of the FEMContext object (in particular, the element
and variable loop order is switched to avoid superfluous element
reiniting).
There shouldn't be any problem with switching the loop order in the
ordinary solution projection case.
There was a problem hiding this comment.
I'll add to this discussion by saying that we have our own reimplementation of project_solution for many of the same reasons (efficiency and calling our own custom objects).
|
libMesh - C++ Finite Element Library » libmesh #131 SUCCESS |
|
libMesh - C++ Finite Element Library » libmesh #133 SUCCESS |
|
Is this passing your tests after the side/edge fixes? I don't see any other problems that would preclude merging. |
|
It does appear to be functional now. However, I haven't yet addressed the code duplication issue. Do you still want me to take a look at that before merging this? |
|
On Tue, 22 Jan 2013, Paul T. Bauman wrote:
Up to you. If you're starting to depend on this functionality in |
|
My data type commits probably completely hosed you here; let me know if you want me to update your stuff (and merge it if you're ready). |
FEMFunctionBase objects. Still untested.
…ting out the context.side issue.
|
libMesh - C++ Finite Element Library » libmesh #237 SUCCESS |
|
OK, I rebased off the current master. I think, given Roy's previous comments, I'd like to get this in now for the 0.9.0 release and open a separate issue to track the refactoring to get rid of the code duplication. Ben, any strong objections? |
|
No strong issues. I'll bug you to refactor if and when this section of code needs an update. ;-) |
Add System::project_solution/System::project_vector methods utilizing FEMFunctionBase functors
This adds the capability for the user to projection_solution using a FEMFunctionBase object. This required updating FEMFunctionBase to behave similarly to FunctionBase objects, including adding some pure virtual methods that will need to be implemented in any user codes (Vikram is the only other user of these that I'm currently aware of). The key difference in the FEMFunctionBase is the operator() methods will have access to a FEMContext object. The implementation of project_vector is very similar to the other methods, with a fair bit of copy/pasted code, but I use the FEMContext object that gets constructed to setup shape functions etc.
In short, the use case for this was for me to be able to create an output system and use a FEMFunctionBase object to project auxiliary quantities computed from my main multiphysics system; this is accomplished by caching a FEMContext from the multiphysics system in the FEMFunctionBase object.
I've updated adjoints_ex3 to implement pure virtual methods that were added, but there's no explicit use of these methods in the library yet - just my successful test in my application code. Any suggestions for adding to an existing example that would be quick? Otherwise, this tested cleanly with --enable-everything, MPI, TBB, and MPI+TBB. Did not try complex.