From: Roy S. <roy...@ic...> - 2012-05-10 22:37:48
|
Paul Bauman has an application that's motivating him to put vector-valued FE capabilities into libMesh, and I've got a shame-this-wasnt-done-years-ago that's motivating me to help, so we're hashing out design ideas now. Two design decisions that've come up, submitted for general commentary: 1.: For vector-valued data, it would be good to return shape values as a vector-of-vector-of-Gradients instead of vector-of-vector-of-Numbers, and shape derivatives would be a vector-of-vector-of-Tensors. (we'll probably postpone second derivative support and add a Rank3Tensor class or some such for it). All agreed? The alternative (returning vector-of-vector-of-vector-of-Numbers, etc) would be much uglier for user code. The catch with this is that the current FEBase already stores vector-of-vector-of-Numbers. And returns it, directly, via inline get_phi(). So, 2.: Do we create FEAbstract, which doesn't include *phi* data or get_*phi* methods, then derive FEBase and FEVectorBase from it? Or do we just add get_vec_*phi* methods (and vec_*phi data) to FEBase? With the latter option, we'd have a bunch of redundant (albeit empty) vectors in every FEBase, and trying to access scalar data from a vector element type or vice-versa would be a runtime error (or possibly only an assert), not very type safe. With the former option, we'd end up having to turn get_*phi* from inline functions into virtual functions. This is what we're leaning towards. The cost of a virtual function is relatively trivial when amortized. I benchmark a few percent overhead when compared to even dead simple bilinear-fe linear residual-type loops, a few thousandths of a percent overhead when compared to biquadratic slightly nonlinear jacobian-type loops. The cost of preventing crazy optimizations can be huge: in the inlined case icpc originally detected that my fakey benchmark couldn't be changing phi in-between get_phi calls, reordered my loops to make the element loop the inner loop, then vectorized and combined my equations to chop out 90% of the FLOPs... but even a slight added code complication (a do-nothing but non-const method called on the fake FE object) took things back to normal; I can't imagine anything similar affecting a real code where we call FE::reinit on every element. --- Roy |
From: Kirk, B. (JSC-EG311) <ben...@na...> - 2012-05-10 22:50:47
|
I always cache a reference to the shape function vectors I need outside the element loop so in this case I can't imagine there is a difference between an inline and virtual function call. -Ben On May 10, 2012, at 5:37 PM, "Roy Stogner" <roy...@ic...> wrote: > > Paul Bauman has an application that's motivating him to put > vector-valued FE capabilities into libMesh, and I've got a > shame-this-wasnt-done-years-ago that's motivating me to help, so we're > hashing out design ideas now. > > Two design decisions that've come up, submitted for general commentary: > > > 1.: For vector-valued data, it would be good to return shape values as > a vector-of-vector-of-Gradients instead of > vector-of-vector-of-Numbers, and shape derivatives would be a > vector-of-vector-of-Tensors. (we'll probably postpone second > derivative support and add a Rank3Tensor class or some such for it). > > All agreed? The alternative (returning > vector-of-vector-of-vector-of-Numbers, etc) would be much uglier for > user code. > > > The catch with this is that the current FEBase already stores > vector-of-vector-of-Numbers. And returns it, directly, via inline > get_phi(). > > > So, 2.: Do we create FEAbstract, which doesn't include *phi* data or > get_*phi* methods, then derive FEBase and FEVectorBase from it? Or do > we just add get_vec_*phi* methods (and vec_*phi data) to FEBase? > > With the latter option, we'd have a bunch of redundant (albeit empty) > vectors in every FEBase, and trying to access scalar data from a > vector element type or vice-versa would be a runtime error (or > possibly only an assert), not very type safe. > > With the former option, we'd end up having to turn get_*phi* from > inline functions into virtual functions. This is what we're leaning > towards. The cost of a virtual function is relatively trivial when > amortized. I benchmark a few percent overhead when compared to even > dead simple bilinear-fe linear residual-type loops, a few thousandths > of a percent overhead when compared to biquadratic slightly nonlinear > jacobian-type loops. > > The cost of preventing crazy optimizations can be huge: in the inlined > case icpc originally detected that my fakey benchmark couldn't be > changing phi in-between get_phi calls, reordered my loops to make the > element loop the inner loop, then vectorized and combined my equations > to chop out 90% of the FLOPs... but even a slight added code > complication (a do-nothing but non-const method called on the fake FE > object) took things back to normal; I can't imagine anything similar > affecting a real code where we call FE::reinit on every element. > --- > Roy > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Libmesh-devel mailing list > Lib...@li... > https://lists.sourceforge.net/lists/listinfo/libmesh-devel |
From: Roy S. <roy...@ic...> - 2012-05-10 22:53:50
|
On Thu, 10 May 2012, Kirk, Benjamin (JSC-EG311) wrote: > I always cache a reference to the shape function vectors I need > outside the element loop so in this case I can't imagine there is a > difference between an inline and virtual function call. You'd be surprised - in my degenerate "icpc figured out this benchmark was a hokey trick" case, the non-virtual loop still ended up being significantly faster. But yeah, for a real problem your strategy would leave no difference whatsoever. --- Roy |
From: John P. <jwp...@gm...> - 2012-05-10 23:00:27
|
On Thu, May 10, 2012 at 4:37 PM, Roy Stogner <roy...@ic...> wrote: > > So, 2.: Do we create FEAbstract, which doesn't include *phi* data or > get_*phi* methods, then derive FEBase and FEVectorBase from it? Or do > we just add get_vec_*phi* methods (and vec_*phi data) to FEBase? The former sounds pretty good. Might make it a little inconvenient to switch between FEBase and FEVectorBase *within the same code* but how often are you mixing scalar and vector FE types with the same assembly loop? Would e.g. the FEMSystem hold a pointer to FEAbstract and then dynamically allocate the proper underlying derived type based on what the types of variables were added? -- John |
From: Roy S. <roy...@ic...> - 2012-05-10 23:13:57
|
On Thu, 10 May 2012, John Peterson wrote: > On Thu, May 10, 2012 at 4:37 PM, Roy Stogner <roy...@ic...> wrote: >> >> So, 2.: Do we create FEAbstract, which doesn't include *phi* data or >> get_*phi* methods, then derive FEBase and FEVectorBase from it? Or do >> we just add get_vec_*phi* methods (and vec_*phi data) to FEBase? > > The former sounds pretty good. > > Might make it a little inconvenient to switch between FEBase and > FEVectorBase *within the same code* but how often are you mixing > scalar and vector FE types with the same assembly loop? Right. Utility codes would need to be changed (e.g. I have a code for visualizing smoothed gradients of arbitrary restart files) before they could handle loading systems with vector-valued FE spaces, but app codes wouldn't encounter such a space unless the app itself created it. Some of the library code will need modification (anything that uses projections, either for their own sake or to calculate constraints), and I'm still trying to figure out if there's a smooth way to do vector/scalar-independent ErrorEstimator code. > Would e.g. the FEMSystem hold a pointer to FEAbstract and then > dynamically allocate the proper underlying derived type based on what > the types of variables were added? FEMContext, you mean? In hindsight we shouldn't be exposing element_fe etc. without hiding them behind accessors. We'll probably have to have leave those targets as FEBase* for backwards compatibility, but add FEVectorBase* map/vector structures for any vector-valued variables, possibly along with proper accessor methods for newer codes to use. --- Roy |
From: Roy S. <roy...@ic...> - 2012-05-10 23:06:05
|
On Thu, 10 May 2012, Boyce Griffith wrote: > Is it feasible to template over the return type in FEBase and then have the > derived classes pick either scalar or vector versions? Hmm... yes, actually. We'd need some kind of traits classes to tell the code that GradientOf<Number>::type is Gradient and GradientOf<Gradient>::type is Tensor, but that would be doable. Not sure if it'd be much of a simplification or not. > Although this would seem to be a pretty big design change . . . I definitely *don't* want any application-level API changes if we can help it. The goal is that app codes would work unmodified and even utility codes would still work if they were presented with data files that didn't include any vector-valued variables. To be that careful, we couldn't actually template FEBase itself (even with a default template parameter specified), but we could have it inherit from something templated. Even that would risk breaking 3rd party FEBase subclasses if they referred to FEBase members with e.g. "phi" instead of "this->phi", but I'd be willing to go that far. I don't think we have any 3rd party FEBase subclasses, and I do think C++ programmers should know by now to future-proof their code against two-phase-name-lookup-induced bugs. Everybody should remember to prepend "this->" if referring to member variables and prepend "What the hell, man?" if talking to Stroustrop. --- Roy |
From: Boyce G. <gri...@ci...> - 2012-05-10 23:48:45
|
On 5/10/12 7:05 PM, Roy Stogner wrote: > > On Thu, 10 May 2012, Boyce Griffith wrote: > >> Is it feasible to template over the return type in FEBase and then >> have the derived classes pick either scalar or vector versions? > > Hmm... yes, actually. We'd need some kind of traits classes to tell > the code that GradientOf<Number>::type is Gradient and > GradientOf<Gradient>::type is Tensor, but that would be doable. Not > sure if it'd be much of a simplification or not. It certainly does not seem like a simplification, at least for the library code --- the only really compelling reason to do this, I think, is to avoid the virtual functions. -- Boyce |
From: Roy S. <roy...@ic...> - 2012-05-10 23:26:21
|
On Thu, 10 May 2012, Roy Stogner wrote: > So, 2.: Do we create FEAbstract, which doesn't include *phi* data or > get_*phi* methods, then derive FEBase and FEVectorBase from it? Or do > we just add get_vec_*phi* methods (and vec_*phi data) to FEBase? > > With the latter option, we'd have a bunch of redundant (albeit empty) > vectors in every FEBase, and trying to access scalar data from a > vector element type or vice-versa would be a runtime error (or > possibly only an assert), not very type safe. > > With the former option, we'd end up having to turn get_*phi* from > inline functions into virtual functions. Wait a minute... no we wouldn't. Anything only defined in one subclass (like get_*phi*) wouldn't need to be represented in the abstract base, anything implementable in the abstract base (like get_JxW etc) wouldn't need to be virtual. compute_shape_functions would need to be virtual, but it's *already* virtual thanks to the needs of InfFE and FEXYZ. The FEAbstract option is looking better than I'd feared from that quick "WTF a few virtual functions can slow down code by a factor of 10!?" experiment. --- Roy |
From: Derek G. <fri...@gm...> - 2012-05-11 00:23:44
|
As long as we're on this subject let me throw a few things out there.... I've recently spent a good amount of time optimizing our variable value / gradient / second derivative evaluation code. I've been trying to get as much of it to vectorize as possible using the Intel compiler. This is important to us because we have a _lot_ of variables and a lot of quadrature points (because we sometimes use high order FEs). When I say a lot... I just had one of our users come in and say that he is going to be using 4000 variables soon. Also, I just ran a simulation with 1,024 variables... with the whole simulation totaling over 100 Million DoFs. When you have this many variables, just computing their values and gradients at the quadrature points becomes a significant burden... What I've run into though is that there is no good way to get gradient evaluation vectorized because we are working with vectors of Gradient objects... meaning that the values themselves are not contiguous in memory. So when we're doing something like this: for (unsigned int i=0; i < num_dofs; i++) { soln_local = current_solution(dof_indices[i]); for (unsigned int qp=0; qp < nqp; qp++) grad_u_qp->add_scaled(grad_phi[i][qp], soln_local); } that inner for loop can't be vectorized because those grad_phi[i][qp] objects aren't contiguous memory. I tried reading them out into a flat vector and then vectorizing that operation... and it did work (the actual multiply by the solution only took microseconds) but the time to read the grads out into a flat vector and then put them back into Gradient objects outweighed the fact that the normal code can't be vectorized (although, not by as much as you would expect!). If we're redesigning this stuff... is there any way we could come up with an interface that would give us flat vectors (I would love it if I could get back one long vector that contained all of the gradients evaluated at each quadrature point for each shape function... this would make it much more amenable to vectorization AND to GPU computation....)? Vectorization is becoming much more important these days.... the new Sandybridge architecture from Intel and Interlagos from AMD can both double the number of FLOPs they do per cycle compared to previous gen processors for multiply-add operations (which is exactly what we're doing!) but only if you're utilizing the vector ops... Another thing: We are now supporting multiply dimensioned pieces of mesh in the same mesh (ie we have 1D elements and 3D elements in the same mesh... but not sharing nodes (although they do transfer information back and forth)). In order to do that seamlessly we have to copy the shape function values in and out of internal data structures. It would be awesome if we could _pass in_ the vectors to be filled by libMesh instead of having libMesh own the data and pass us back references. Then we could avoid a lot of copying by passing the same vector to be filled into multiple FE objects (that are of different dimension) and asking them to fill those vectors when we're on the corresponding elements... Just some junk to think about while we're redesigning some of this stuff. Derek On Thu, May 10, 2012 at 4:37 PM, Roy Stogner <roy...@ic...>wrote: > > Paul Bauman has an application that's motivating him to put > vector-valued FE capabilities into libMesh, and I've got a > shame-this-wasnt-done-years-ago that's motivating me to help, so we're > hashing out design ideas now. > > Two design decisions that've come up, submitted for general commentary: > > > 1.: For vector-valued data, it would be good to return shape values as > a vector-of-vector-of-Gradients instead of > vector-of-vector-of-Numbers, and shape derivatives would be a > vector-of-vector-of-Tensors. (we'll probably postpone second > derivative support and add a Rank3Tensor class or some such for it). > > All agreed? The alternative (returning > vector-of-vector-of-vector-of-Numbers, etc) would be much uglier for > user code. > > > The catch with this is that the current FEBase already stores > vector-of-vector-of-Numbers. And returns it, directly, via inline > get_phi(). > > > So, 2.: Do we create FEAbstract, which doesn't include *phi* data or > get_*phi* methods, then derive FEBase and FEVectorBase from it? Or do > we just add get_vec_*phi* methods (and vec_*phi data) to FEBase? > > With the latter option, we'd have a bunch of redundant (albeit empty) > vectors in every FEBase, and trying to access scalar data from a > vector element type or vice-versa would be a runtime error (or > possibly only an assert), not very type safe. > > With the former option, we'd end up having to turn get_*phi* from > inline functions into virtual functions. This is what we're leaning > towards. The cost of a virtual function is relatively trivial when > amortized. I benchmark a few percent overhead when compared to even > dead simple bilinear-fe linear residual-type loops, a few thousandths > of a percent overhead when compared to biquadratic slightly nonlinear > jacobian-type loops. > > The cost of preventing crazy optimizations can be huge: in the inlined > case icpc originally detected that my fakey benchmark couldn't be > changing phi in-between get_phi calls, reordered my loops to make the > element loop the inner loop, then vectorized and combined my equations > to chop out 90% of the FLOPs... but even a slight added code > complication (a do-nothing but non-const method called on the fake FE > object) took things back to normal; I can't imagine anything similar > affecting a real code where we call FE::reinit on every element. > --- > Roy > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Libmesh-devel mailing list > Lib...@li... > https://lists.sourceforge.net/lists/listinfo/libmesh-devel > |
From: David K. <dkn...@se...> - 2012-05-11 01:21:57
|
On 05/10/2012 06:37 PM, Roy Stogner wrote: > Paul Bauman has an application that's motivating him to put > vector-valued FE capabilities into libMesh, and I've got a > shame-this-wasnt-done-years-ago that's motivating me to help, so we're > hashing out design ideas now. I'm curious, what type of vector-valued elements are on the drawing board? Nedelec? Raviart-Thomas? |
From: Paul T. B. <ptb...@gm...> - 2012-05-11 01:28:18
|
On Thu, May 10, 2012 at 8:21 PM, David Knezevic <dkn...@se...>wrote: > > I'm curious, what type of vector-valued elements are on the drawing > board? Nedelec? Raviart-Thomas? > Nedelec ASAP and RT will likely follow shortly thereafter. Best, Paul |
From: David K. <dkn...@se...> - 2012-05-11 01:29:00
|
On 05/10/2012 09:28 PM, Paul T. Bauman wrote: > On Thu, May 10, 2012 at 8:21 PM, David Knezevic > <dkn...@se... <mailto:dkn...@se...>> wrote: > > > I'm curious, what type of vector-valued elements are on the drawing > board? Nedelec? Raviart-Thomas? > > > Nedelec ASAP and RT will likely follow shortly thereafter. That's awesome. |
From: Roy S. <roy...@ic...> - 2012-05-24 15:51:30
|
On Thu, 10 May 2012, Derek Gaston wrote: > As long as we're on this subject let me throw a few things out there.... Between illness and work and the renumbering discussion I let this slip... > What I've run into though is that there is no good way to get gradient > evaluation vectorized because we are working with vectors of Gradient > objects... meaning that the values themselves are not contiguous in memory. > So when we're doing something like this: > > for (unsigned int i=0; i < num_dofs; i++) > { > soln_local = current_solution(dof_indices[i]); > > for (unsigned int qp=0; qp < nqp; qp++) > grad_u_qp->add_scaled(grad_phi[i][qp], soln_local); > } > > that inner for loop can't be vectorized because those grad_phi[i][qp] > objects aren't contiguous memory. I've seen this problem with non-gradients: we want qp to be incremented in the outer loop, because there's solution variables to be assembled and/or nonlinear constitutive terms to be evaluated at each quadrature point, but then the inner loop is not vectorizable because we're iterating over phi[i][qp] rather than phi[qp][i]. I've got a couple ideas that might fix that (and give you your flat vectors, now that you mention it) in the long run. But... since when are grad_phi_i[qp] objects not continuous memory? If the underlying data there isn't an n_qp*LIBMESH_DIM array of Real, then something's going wrong under the hood. > We are now supporting multiply dimensioned pieces of mesh in the same mesh > (ie we have 1D elements and 3D elements in the same mesh... but not sharing > nodes (although they do transfer information back and forth)). In order to > do that seamlessly we have to copy the shape function values in and out of > internal data structures. It would be awesome if we could _pass in_ the > vectors to be filled by libMesh instead of having libMesh own the data and > pass us back references. Then we could avoid a lot of copying by passing > the same vector to be filled into multiple FE objects (that are of different > dimension) and asking them to fill those vectors when we're on the > corresponding elements... Hmmm... I'm still not seeing how this is useful (why make a copy rather than just pass around the original?) but it wouldn't be too hard to support. Probably falls underneath "vectorize the shape function calls in reinit()" on my eternally growing TODO list, though. --- Roy |
From: Paul T. B. <ptb...@gm...> - 2012-05-30 17:19:35
|
All, I've attached a patch and two files for step 0 on this (drop fe_abstract.h and fe_abstract.C in include/fe and src/fe respectively - svn cp doesn't really yield proper patches). You can also find them here if the list filters them out: http://users.ices.utexas.edu/~pbauman/fe_abstract/ This moves common stuff into the newly created FEAbstract class from which FEBase now derives (and future FEVectorBase will derive). Things that directly call get_phi() etc, are still in FEBase - with the exception of the geometry maps which always instantiate Lagrange elements, so they got left in FEAbstract. No new virtual functions were created and the only call outside these classes changed was compute_map(). I haven't noticed any peformance regressions, but please let me know if they pop up for you. I didn't feel comfortable committing this without some more scrutiny and testing. trunk at r5642 is passing all the examples on my workstation; however, miscellaneous_ex6 dies with a segfault on my mac, but it seems unrelated to this patch (I'm still investigating - Valgrind runs clean on my workstation). Roy, could you particularly look at fe_abstract.C in the compute_node_constraints function? I believe I integrated your changes in r5642 correctly, but it's worth double checking because I'm sure it's currently being exercised by the examples. Feedback welcome. Again, since this is so low level, I don't want to commit without someone else looking/testing this first. The course after this is a little messier. In particular, we need to decide how to handle cases like in exact_error_estimator:352 - call to coarsened_dof_values. We call a static member function of FEBase, but really that shouldn't depend on the FE type (I think) from the error_estimator point of view. Anyways, start tossing stones. Thanks, Paul |
From: John P. <jwp...@gm...> - 2012-05-30 18:57:31
|
On Wed, May 30, 2012 at 11:19 AM, Paul T. Bauman <ptb...@gm...> wrote: > All, > > I've attached a patch and two files for step 0 on this (drop fe_abstract.h > and fe_abstract.C in include/fe and src/fe respectively - svn cp doesn't > really yield proper patches). You can also find them here if the list > filters them out: http://users.ices.utexas.edu/~pbauman/fe_abstract/ > > This moves common stuff into the newly created FEAbstract class from which > FEBase now derives (and future FEVectorBase will derive). Things that > directly call get_phi() etc, are still in FEBase - with the exception of the > geometry maps which always instantiate Lagrange elements, so they got left > in FEAbstract. One question about the design here: H(div) elements will presumably require a different type of mapping [0] than what FEBase currently does with Lagrange. So, should the geometry mapping stuff really be moved up into FEAbstract, or would it be better to have virtual interfaces for that which can be redefined by FEVectorBase? [0] http://www.math.uh.edu/~rohop/spring_11/downloads/Chapter7.pdf, pg. 17 -- John |
From: Paul T. B. <ptb...@gm...> - 2012-05-30 19:10:59
|
On Wed, May 30, 2012 at 1:57 PM, John Peterson <jwp...@gm...> wrote: > One question about the design here: H(div) elements will presumably > require a different type of mapping [0] than what FEBase currently > does with Lagrange. > > So, should the geometry mapping stuff really be moved up into > FEAbstract, or would it be better to have virtual interfaces for that > which can be redefined by FEVectorBase? > My thinking was to create a PiolaTransformation object which augmented the current mapping within the FEVectorBase class because it looked like to me that you always have a composition with the H1 conforming case. But maybe I missed something? It also may be more clear to explicitly do this for each "branch" of FE. Thoughts? Thanks for the comments. Paul |
From: John P. <jwp...@gm...> - 2012-05-30 19:24:28
|
On Wed, May 30, 2012 at 1:10 PM, Paul T. Bauman <ptb...@gm...> wrote: > On Wed, May 30, 2012 at 1:57 PM, John Peterson <jwp...@gm...> wrote: >> >> One question about the design here: H(div) elements will presumably >> require a different type of mapping [0] than what FEBase currently >> does with Lagrange. >> >> So, should the geometry mapping stuff really be moved up into >> FEAbstract, or would it be better to have virtual interfaces for that >> which can be redefined by FEVectorBase? > > > My thinking was to create a PiolaTransformation object which augmented the > current mapping within the FEVectorBase class This sounds fine to me... > because it looked like to me that you always have a composition with the H1 conforming case. ...if that statement is true. It's true for H(div), but I can't really comment on the specifics of other vector-valued bases. H(curl)? > But maybe I missed something? It also may be more clear to explicitly do this for each > "branch" of FE. Thoughts? It might be possible to have a more complete separation between the mapping aspects of the FE class and the approximation space aspects, i.e. have an "FEMap" base class and corresponding hierarchy? But there's no reason to worry about that potential design change while you are already immersed in creating FEAbstract... maybe it could be looked at again later if it seems useful. -- John |
From: Roy S. <roy...@ic...> - 2012-05-30 19:40:30
|
On Wed, 30 May 2012, John Peterson wrote: > It might be possible to have a more complete separation between the > mapping aspects of the FE class and the approximation space aspects, > i.e. have an "FEMap" base class and corresponding hierarchy? I personally would be thrilled if we could generalize to non-Lagrange maps. I haven't drunk the NURBS-approximation-spaces Flavor-Aid yet, but supporting NURBS geometric mappings would be fantastic. I think it's a red herring from the vector valued elements questions, however. The (Lagrange-or-NURBs-or-high_p-etc) option on mappings from reference to physical space ought to be completely independent of the (covariant-or-contravariant-or-piola) option for the subsequently induced mappings from reference to physical vectors (or tensors). > But there's no reason to worry about that potential design change > while you are already immersed in creating FEAbstract... maybe it > could be looked at again later if it seems useful. Agreed. --- Roy |
From: Paul T. B. <ptb...@gm...> - 2012-05-30 19:45:56
|
On Wed, May 30, 2012 at 2:40 PM, Roy Stogner <roy...@ic...>wrote: > > On Wed, 30 May 2012, John Peterson wrote: > > It might be possible to have a more complete separation between the >> mapping aspects of the FE class and the approximation space aspects, >> i.e. have an "FEMap" base class and corresponding hierarchy? >> > > I personally would be thrilled if we could generalize to non-Lagrange > maps. I haven't drunk the NURBS-approximation-spaces Flavor-Aid yet, > but supporting NURBS geometric mappings would be fantastic. > > I think it's a red herring from the vector valued elements questions, > however. The (Lagrange-or-NURBs-or-high_p-**etc) option on mappings > from reference to physical space ought to be completely independent of > the (covariant-or-contravariant-**or-piola) option for the subsequently > induced mappings from reference to physical vectors (or tensors). You're correct here I think. Although my comment before applies to H(curl), the actual transformation is different than the H(div) case, so seems to make sense to generalize the mapping concept. > > But there's no reason to worry about that potential design change >> while you are already immersed in creating FEAbstract... maybe it >> could be looked at again later if it seems useful. >> > > Agreed. > Cool. I think it'll come up again in a big hurry, but I think it will be better/easier to deal with once the details become more concrete. FYI, I can reproduce the miscellaneous_ex6 problem in absence of my patch on my mac, so it seems orthogonal. Other comments before I commit? Thanks, Paul |
From: John P. <jwp...@gm...> - 2012-05-30 20:15:47
|
On Wed, May 30, 2012 at 1:45 PM, Paul T. Bauman <ptb...@gm...> wrote: > > Other comments before I commit? I'm rebuilding our stack now and will run our tests if you can wait a bit... -- John |
From: Paul T. B. <ptb...@gm...> - 2012-05-30 20:22:20
|
On Wed, May 30, 2012 at 3:15 PM, John Peterson <jwp...@gm...> wrote: > On Wed, May 30, 2012 at 1:45 PM, Paul T. Bauman <ptb...@gm...> > wrote: > > > > Other comments before I commit? > > I'm rebuilding our stack now and will run our tests if you can wait a > bit... > Definitely not a problem. Take as long as you need. Thanks. |
From: John P. <jwp...@gm...> - 2012-05-30 20:24:19
|
On Wed, May 30, 2012 at 2:15 PM, John Peterson <jwp...@gm...> wrote: > On Wed, May 30, 2012 at 1:45 PM, Paul T. Bauman <ptb...@gm...> wrote: >> >> Other comments before I commit? > > I'm rebuilding our stack now and will run our tests if you can wait a bit... Here's one error: /Users/petejw/projects/libmesh_git/include/fe/fe_base.h: In constructor ‘libMesh::FEBase::FEBase(unsigned int, const libMesh::FEType&)’: /Users/petejw/projects/libmesh_git/include/fe/fe_base.h:593: error: expected identifier before ‘{’ token /Users/petejw/projects/libmesh_git/include/fe/fe_base.h:593: error: expected `(' before ‘{’ token I do not have LIBMESH_ENABLE_INFINITE_ELEMENTS defined, so this constructor list has a trailing comma? -- John |
From: John P. <jwp...@gm...> - 2012-05-30 21:02:25
|
On Wed, May 30, 2012 at 2:29 PM, Paul T. Bauman <ptb...@gm...> wrote: > > On Wed, May 30, 2012 at 3:23 PM, John Peterson <jwp...@gm...> wrote: >> >> Here's one error: >> >> /Users/petejw/projects/libmesh_git/include/fe/fe_base.h: In >> constructor ‘libMesh::FEBase::FEBase(unsigned int, const >> libMesh::FEType&)’: >> /Users/petejw/projects/libmesh_git/include/fe/fe_base.h:593: error: >> expected identifier before ‘{’ token >> /Users/petejw/projects/libmesh_git/include/fe/fe_base.h:593: error: >> expected `(' before ‘{’ token >> >> I do not have LIBMESH_ENABLE_INFINITE_ELEMENTS defined, so this >> constructor list has a trailing comma? > > > That's what I get for trying with --enable-everything. Here's a patch for > fe_base.h (against trunk) that should fix that. Your second patch isn't really a great fix, since technically things should be initialized in the constructor in the order they are declared in the class, but, thinking about it for a moment, this constructor is just oddly-written in general: there's not really any need to call all these vector default constructors explicitly. Probably just really old code I'm guessing...should be fine to just delete all of those guys. Anyway, all our tests seem to pass here. -- John |
From: Paul T. B. <ptb...@gm...> - 2012-05-30 21:07:31
|
On Wed, May 30, 2012 at 4:01 PM, John Peterson <jwp...@gm...> wrote: > Your second patch isn't really a great fix, since technically things > should be initialized in the constructor in the order they are > declared in the class, You're right, of course. > but, thinking about it for a moment, this > constructor is just oddly-written in general: there's not really any > need to call all these vector default constructors explicitly. > Probably just really old code I'm guessing...should be fine to just > delete all of those guys. > I'm OK either way - I can reorder the declarations in the class or I can remove the explicit constructor calls, whichever you folks prefer (I'm leaning towards removing them). > > Anyway, all our tests seem to pass here. Awesome, thanks. |
From: John P. <jwp...@gm...> - 2012-05-30 21:08:20
|
On Wed, May 30, 2012 at 3:01 PM, John Peterson <jwp...@gm...> wrote: > On Wed, May 30, 2012 at 2:29 PM, Paul T. Bauman <ptb...@gm...> wrote: >> >> On Wed, May 30, 2012 at 3:23 PM, John Peterson <jwp...@gm...> wrote: >>> >>> Here's one error: >>> >>> /Users/petejw/projects/libmesh_git/include/fe/fe_base.h: In >>> constructor ‘libMesh::FEBase::FEBase(unsigned int, const >>> libMesh::FEType&)’: >>> /Users/petejw/projects/libmesh_git/include/fe/fe_base.h:593: error: >>> expected identifier before ‘{’ token >>> /Users/petejw/projects/libmesh_git/include/fe/fe_base.h:593: error: >>> expected `(' before ‘{’ token >>> >>> I do not have LIBMESH_ENABLE_INFINITE_ELEMENTS defined, so this >>> constructor list has a trailing comma? >> >> >> That's what I get for trying with --enable-everything. Here's a patch for >> fe_base.h (against trunk) that should fix that. > > Your second patch isn't really a great fix, since technically things > should be initialized in the constructor in the order they are > declared in the class, but, thinking about it for a moment, this > constructor is just oddly-written in general: there's not really any > need to call all these vector default constructors explicitly. > Probably just really old code I'm guessing...should be fine to just > delete all of those guys. Although svn blame tells me Roy added all these recently on 13 Jan 2011, so he will enlighten me hopefully. -- John |