From: Vijay S. M. <vi...@gm...> - 2010-10-01 00:33:30
|
Hi all, I am working on system that requires me to start with a 4th order element since the mesh for the domain is prescribed from an external source. Now, since libMesh does not have 4th order lagrangian elements and since I'm lazy to learn a new package (and since I'm constrained in time), I decided to implement higher order lagrange elements (EDGE, QUAD, HEX only for now) till order 5. But on my first look to proceed with this idea, I noticed that there is an embedding matrix that is prescribed for every element. And I do not exactly understand the usage of this array in the bigger picture. If someone can help me understand what exactly it represents, it would be tremendously helpful for me in the implementation. I might have posed a similar question couple of years ago in the context of higher order elements but when I'm done testing, I definitely can create a patch to add the functionality to the library, even though my focus is only for limited elements. Thanks, vijay |
From: Vijay S. M. <vi...@gm...> - 2010-10-03 20:14:34
|
I sent this email couple days back but have not received any reply yet. I know you guys are busy but it would help me quite a bit in completing the implementation if one of the developers can explain the purpose of the embedding matrix. I have implemented higher order lagrange basis for 1-d elements (till EDGE6) and am in the process of testing 2-d quad elements (QUAD16, QUAD25). But I have another question regarding the 2-d elements. What are the i0 and i1 arrays in fe_lagrange_shape_2d.C ? I am sure they represent some array indices to access data for the nodes in the element but the numbering is not completely obvious to me. If someone can shed some light on this part of the code, that will be helpful too. I have been testing my codes primarily with ex4 using higher order lagrange basis. I have not implemented any extensions/modifications for AMR capabilities with these higher order elements but if you can point out possible locations that might need modifications for this capability, I can look at these before sending you a patch. Vijay On Thu, Sep 30, 2010 at 7:33 PM, Vijay S. Mahadevan <vi...@gm...> wrote: > Hi all, > > I am working on system that requires me to start with a 4th order > element since the mesh for the domain is prescribed from an external > source. Now, since libMesh does not have 4th order lagrangian elements > and since I'm lazy to learn a new package (and since I'm constrained > in time), I decided to implement higher order lagrange elements (EDGE, > QUAD, HEX only for now) till order 5. But on my first look to proceed > with this idea, I noticed that there is an embedding matrix that is > prescribed for every element. And I do not exactly understand the > usage of this array in the bigger picture. If someone can help me > understand what exactly it represents, it would be tremendously > helpful for me in the implementation. > > I might have posed a similar question couple of years ago in the > context of higher order elements but when I'm done testing, I > definitely can create a patch to add the functionality to the library, > even though my focus is only for limited elements. > > Thanks, > vijay > |
From: Derek G. <fri...@gm...> - 2010-10-03 23:00:53
|
Vijay, I just wanted to let you know that this work is greatly appreciated! I know we could certainly do some things with higher order Lagrange shape functions! That said... I know next to nothing about that piece of the code... and unfortunately the guys who do know something are EXTREMELY tied up with a program review this week. Just thought I would shed some light on the delay in help... Derek Sent from my iPhone On Oct 3, 2010, at 3:14 PM, "Vijay S. Mahadevan" <vi...@gm...> wrote: > I sent this email couple days back but have not received any reply > yet. I know you guys are busy but it would help me quite a bit in > completing the implementation if one of the developers can explain the > purpose of the embedding matrix. > > I have implemented higher order lagrange basis for 1-d elements (till > EDGE6) and am in the process of testing 2-d quad elements (QUAD16, > QUAD25). But I have another question regarding the 2-d elements. What > are the i0 and i1 arrays in fe_lagrange_shape_2d.C ? I am sure they > represent some array indices to access data for the nodes in the > element but the numbering is not completely obvious to me. If someone > can shed some light on this part of the code, that will be helpful > too. > > I have been testing my codes primarily with ex4 using higher order > lagrange basis. I have not implemented any extensions/modifications > for AMR capabilities with these higher order elements but if you can > point out possible locations that might need modifications for this > capability, I can look at these before sending you a patch. > > Vijay > > On Thu, Sep 30, 2010 at 7:33 PM, Vijay S. Mahadevan <vi...@gm...> wrote: >> Hi all, >> >> I am working on system that requires me to start with a 4th order >> element since the mesh for the domain is prescribed from an external >> source. Now, since libMesh does not have 4th order lagrangian elements >> and since I'm lazy to learn a new package (and since I'm constrained >> in time), I decided to implement higher order lagrange elements (EDGE, >> QUAD, HEX only for now) till order 5. But on my first look to proceed >> with this idea, I noticed that there is an embedding matrix that is >> prescribed for every element. And I do not exactly understand the >> usage of this array in the bigger picture. If someone can help me >> understand what exactly it represents, it would be tremendously >> helpful for me in the implementation. >> >> I might have posed a similar question couple of years ago in the >> context of higher order elements but when I'm done testing, I >> definitely can create a patch to add the functionality to the library, >> even though my focus is only for limited elements. >> >> Thanks, >> vijay >> > > ------------------------------------------------------------------------------ > Virtualization is moving to the mainstream and overtaking non-virtualized > environment for deploying applications. Does it make network security > easier or more difficult to achieve? Read this whitepaper to separate the > two and get a better understanding. > http://p.sf.net/sfu/hp-phase2-d2d > _______________________________________________ > Libmesh-devel mailing list > Lib...@li... > https://lists.sourceforge.net/lists/listinfo/libmesh-devel |
From: Vijay S. M. <vi...@gm...> - 2010-10-04 02:59:47
|
Apparently I bcc'd the list my previous mail. John, sorry if you get this twice (or thrice ?!).. Guess only some sleep and coffee can cure my stupidities .. Derek, Absolutely. I have been asked to use higher order lagrange basis before but have always tried to convince people to instead live with Hierarchical bases. But in my current work, it has become unavoidable and so finally I gave in to the idea of adding these to the library. I was hoping that more people will be able to use it and glad to know that atleast you and others will find it useful ! John, I've included the devel list to your reply because you sent the mail only to me. As you rightly point out, my higher order lagrange are only tensor products and as I mentioned before in my email, I'm implementing them only for (EDGE, QUAD and HEX) which precisely use this formulation. The explanation for the embedding matrix makes sense and I will look at the Quad implementations to see if I can derive them accordingly. My node orderings for EDGE's are pretty straightforward and they follow the convention. But my QUAD's, I'm not sure if this would be your expected ordering. Here they are. * 3 9 8 2 * QUAD16: o-----o-----o-----o * | | * | 15 14 | * 10 o o o o 7 * | | * | | * | 12 13 | * 11 o o o o 6 * | | * | | * o-----o-----o-----o * 0 4 5 1 * 3 12 11 10 2 * QUAD25: o-----o-----o-----o-----o * | | * | 22 21 20 | * 13 o o o o o 9 * | | * | | * | 23 24 19 | * 14 o o o o o 8 * | | * | | * | 16 17 18 | * 15 o o o o o 7 * | | * | | * o-----o-----o-----o-----o * 0 4 5 6 1 Let me know if this is logical enough to create child elements from this parent. The numbering essentially goes for vertices first, side nodes next and finally the internal nodes (all in anti-clockwise direction). If you think there is a better numbering that would enable a smoother AMR algorithm, feel free to suggest an alternative. I also need to know about the i0 and i1 arrays in lagrange_2d_shape.C. Without the correct order, the tensor products will not be computed correctly and my tired brain seems to go blank looking at it. A simple explanation for this and I should almost be set to test the 2-D elements tomorrow. Thanks for the help. Vijay On Sun, Oct 3, 2010 at 7:55 PM, John Peterson <pet...@cf...> wrote: > On Sun, Oct 3, 2010 at 3:14 PM, Vijay S. Mahadevan <vi...@gm...> wrote: >> >> I have implemented higher order lagrange basis for 1-d elements (till >> EDGE6) and am in the process of testing 2-d quad elements (QUAD16, >> QUAD25). But I have another question regarding the 2-d elements. What >> are the i0 and i1 arrays in fe_lagrange_shape_2d.C ? I am sure they >> represent some array indices to access data for the nodes in the >> element but the numbering is not completely obvious to me. If someone >> can shed some light on this part of the code, that will be helpful >> too. > > These are for doing tensor products of 1D basis function to get 2D > basis functions. For example, the zero'th QUAD bilinear basis > function is given by the product the zero'th 1D basis function (in xi) > and the zero'th 1D basis function (in eta). > > As far as the embedding matrices go, they are basically just tabulated > Lagrange shape function values, used to determine where new nodes will > be inserted for AMR. The simplest one is probably in face_tri3.C, so > I'd start there. The first index is for the child. The second and > third dimensions are indexes into the tabulated shape function values. > So, for example the location of node 0 in the zero'th child of the > Tri3 is 1*phi0 + 0*phi1 + 0*phi2. Likewise the location of node1 in > the zero'th child is 0.5*phi0 + 0.5*phi1 + 0*phi2, and so on. > > By the way, I wonder what node ordering you have chosen for the higher > order Edges, and consequently for the Quads? The second and > first-order nodes are kind of nice in the sense that they are > "nested", i.e. the quadratics reuse all the linear nodes, so no > renumbering is required. This isn't true when you go from Edge3 -> > Edge4 though... > > -- > John > |
From: Vijay S. M. <vi...@gm...> - 2010-10-04 16:16:28
|
John, If I understand the implementation for edges correctly, for all the higher order edges, you split the element in half and create 2 children of same order with h/2. If this is true, I dont see a problem with my numbering scheme or the implementation of the embedding matrix. Btw, here's the numbering for the edges that I missed out in my previous mail. * EGDE5: o----o----o----o----o * 0 2 3 4 1 * EGDE6: o----o----o----o----o----o * 0 2 3 4 5 1 Once I finish testing the 1-d elements completely, I will move to the 2-d elements and implement the embedding and mesh generation algorithms which still need some cleaning up. Let me know if you have any comments. Vijay On Sun, Oct 3, 2010 at 9:59 PM, Vijay S. Mahadevan <vi...@gm...> wrote: > Apparently I bcc'd the list my previous mail. John, sorry if you get > this twice (or thrice ?!).. Guess only some sleep and coffee can cure > my stupidities .. > > Derek, > > Absolutely. I have been asked to use higher order lagrange basis > before but have always tried to convince people to instead live with > Hierarchical bases. But in my current work, it has become unavoidable > and so finally I gave in to the idea of adding these to the library. I > was hoping that more people will be able to use it and glad to know > that atleast you and others will find it useful ! > > John, > > I've included the devel list to your reply because you sent the mail > only to me. > > As you rightly point out, my higher order lagrange are only tensor > products and as I mentioned before in my email, I'm implementing them > only for (EDGE, QUAD and HEX) which precisely use this formulation. > The explanation for the embedding matrix makes sense and I will look > at the Quad implementations to see if I can derive them accordingly. > My node orderings for EDGE's are pretty straightforward and they > follow the convention. But my QUAD's, I'm not sure if this would be > your expected ordering. Here they are. > > * 3 9 8 2 > * QUAD16: o-----o-----o-----o > * | | > * | 15 14 | > * 10 o o o o 7 > * | | > * | | > * | 12 13 | > * 11 o o o o 6 > * | | > * | | > * o-----o-----o-----o > * 0 4 5 1 > > > * 3 12 11 10 2 > * QUAD25: o-----o-----o-----o-----o > * | | > * | 22 21 20 | > * 13 o o o o o 9 > * | | > * | | > * | 23 24 19 | > * 14 o o o o o 8 > * | | > * | | > * | 16 17 18 | > * 15 o o o o o 7 > * | | > * | | > * o-----o-----o-----o-----o > * 0 4 5 6 1 > > Let me know if this is logical enough to create child elements from > this parent. The numbering essentially goes for vertices first, side > nodes next and finally the internal nodes (all in anti-clockwise > direction). If you think there is a better numbering that would enable > a smoother AMR algorithm, feel free to suggest an alternative. > > I also need to know about the i0 and i1 arrays in lagrange_2d_shape.C. > Without the correct order, the tensor products will not be computed > correctly and my tired brain seems to go blank looking at it. A simple > explanation for this and I should almost be set to test the 2-D > elements tomorrow. > > Thanks for the help. > Vijay > > On Sun, Oct 3, 2010 at 7:55 PM, John Peterson > <pet...@cf...> wrote: >> On Sun, Oct 3, 2010 at 3:14 PM, Vijay S. Mahadevan <vi...@gm...> wrote: >>> >>> I have implemented higher order lagrange basis for 1-d elements (till >>> EDGE6) and am in the process of testing 2-d quad elements (QUAD16, >>> QUAD25). But I have another question regarding the 2-d elements. What >>> are the i0 and i1 arrays in fe_lagrange_shape_2d.C ? I am sure they >>> represent some array indices to access data for the nodes in the >>> element but the numbering is not completely obvious to me. If someone >>> can shed some light on this part of the code, that will be helpful >>> too. >> >> These are for doing tensor products of 1D basis function to get 2D >> basis functions. For example, the zero'th QUAD bilinear basis >> function is given by the product the zero'th 1D basis function (in xi) >> and the zero'th 1D basis function (in eta). >> >> As far as the embedding matrices go, they are basically just tabulated >> Lagrange shape function values, used to determine where new nodes will >> be inserted for AMR. The simplest one is probably in face_tri3.C, so >> I'd start there. The first index is for the child. The second and >> third dimensions are indexes into the tabulated shape function values. >> So, for example the location of node 0 in the zero'th child of the >> Tri3 is 1*phi0 + 0*phi1 + 0*phi2. Likewise the location of node1 in >> the zero'th child is 0.5*phi0 + 0.5*phi1 + 0*phi2, and so on. >> >> By the way, I wonder what node ordering you have chosen for the higher >> order Edges, and consequently for the Quads? The second and >> first-order nodes are kind of nice in the sense that they are >> "nested", i.e. the quadratics reuse all the linear nodes, so no >> renumbering is required. This isn't true when you go from Edge3 -> >> Edge4 though... >> >> -- >> John >> > |
From: John P. <pet...@cf...> - 2010-10-04 17:55:47
|
On Mon, Oct 4, 2010 at 11:16 AM, Vijay S. Mahadevan <vi...@gm...> wrote: > John, > > If I understand the implementation for edges correctly, for all the > higher order edges, you split the element in half and create 2 > children of same order with h/2. If this is true, I dont see a problem > with my numbering scheme or the implementation of the embedding > matrix. Btw, here's the numbering for the edges that I missed out in > my previous mail. > > * EGDE5: o----o----o----o----o > * 0 2 3 4 1 Hmm, for EDGE5 I think I'd suggest o----o----o----o----o 0 3 2 4 1 So that it nests with the EDGE3, and I suppose what you have for EDGE6 o----o----o----o----o----o 0 2 3 4 5 1 is OK, there is no nice way to nest orders 4 and 6. Unless you allow non-equispaced nodes on the master element? I don't think there is any equispacing assumption required for the interpolation estimates to hold, but it would probably be at least non-standard and confusing to have them non-equispaced. > Once I finish testing the 1-d elements completely, I will move to the > 2-d elements and implement the embedding and mesh generation > algorithms which still need some cleaning up. Let me know if you have > any comments. Are you planning to use isoparametric elements (element map has same order as basis functions)? If you can stick to quadratic elements for the mappings, I don't *think* you need to add any new embedding matrices, though I could be wrong about that. For higher-order elements the embedding matrices will be enormous, not sure we want to mess with these if we don't have to... -- John |
From: Vijay S. M. <vi...@gm...> - 2010-10-05 00:09:24
|
Yes. I agree that the numbering change for EDGE5 would be logical to be nested with EDGE3. All my nodes are equi-spaced as of now and I don't have any requirements to have a non-standard element definition for any of my problems. > Are you planning to use isoparametric elements (element map has same > order as basis functions)? Yes. > For higher-order elements the embedding matrices will be enormous, not > sure we want to mess with these if we don't have to... Are you saying that higher order elements dont need the embedding matrix defined ? Or am I understanding you wrongly. I am going to try to write a matlab script that will evaluate the basis functions at a given point and that should hopefully minimize all the work for creating these matrices. As long as I specify the right coordinates in the reference element, the embedding matrix should be easy to evaluate. Do you think there is an easier way ? I found another quirk in the EDGE* codes. There is an assert in connectivity() routine as follows: libmesh_assert (sc < this->n_sub_elem()); where sc is the number of linear cells. This is fine till quadratic elements (EDGE3) since sc < 2 but for EDGE4, and higher order elements, this is not true anymore. Should this assert still exist or was there an ulterior motive to placing this in the code ? Since VTK does not support visualizing higher order elements, splitting the elements to many linear elements and writing out the solution at the vertices would require that this condition not be met. Comments ? An alternative is that there are more n_sub_elem() (more than 2) for higher order elements. Is this an option ? Vijay On Mon, Oct 4, 2010 at 12:55 PM, John Peterson <pet...@cf...> wrote: > On Mon, Oct 4, 2010 at 11:16 AM, Vijay S. Mahadevan <vi...@gm...> wrote: >> John, >> >> If I understand the implementation for edges correctly, for all the >> higher order edges, you split the element in half and create 2 >> children of same order with h/2. If this is true, I dont see a problem >> with my numbering scheme or the implementation of the embedding >> matrix. Btw, here's the numbering for the edges that I missed out in >> my previous mail. >> >> * EGDE5: o----o----o----o----o >> * 0 2 3 4 1 > > Hmm, for EDGE5 I think I'd suggest > > o----o----o----o----o > 0 3 2 4 1 > > So that it nests with the EDGE3, and I suppose what you have for EDGE6 > > o----o----o----o----o----o > 0 2 3 4 5 1 > > is OK, there is no nice way to nest orders 4 and 6. Unless you allow > non-equispaced nodes on the master element? I don't think there is > any equispacing assumption required for the interpolation estimates to > hold, but it would probably be at least non-standard and confusing to > have them non-equispaced. > >> Once I finish testing the 1-d elements completely, I will move to the >> 2-d elements and implement the embedding and mesh generation >> algorithms which still need some cleaning up. Let me know if you have >> any comments. > > Are you planning to use isoparametric elements (element map has same > order as basis functions)? If you can stick to quadratic elements for > the mappings, I don't *think* you need to add any new embedding > matrices, though I could be wrong about that. > > For higher-order elements the embedding matrices will be enormous, not > sure we want to mess with these if we don't have to... > > -- > John > |
From: Roy S. <roy...@ic...> - 2010-10-13 16:47:33
|
I'm jumping into this very late; a couple comments: On Mon, 4 Oct 2010, Vijay S. Mahadevan wrote: >> For higher-order elements the embedding matrices will be enormous, not >> sure we want to mess with these if we don't have to... > Are you saying that higher order elements dont need the embedding > matrix defined ? Or am I understanding you wrongly. I think John was saying that higher order elements wouldn't need the embedding matrix defined if they were limited to lower order geometry. > I am going to try to write a matlab script that will evaluate the > basis functions at a given point and that should hopefully minimize > all the work for creating these matrices. As long as I specify the > right coordinates in the reference element, the embedding matrix > should be easy to evaluate. Do you think there is an easier way ? I think this is probably the way to go. > I found another quirk in the EDGE* codes. There is an assert in > connectivity() routine as follows: > > libmesh_assert (sc < this->n_sub_elem()); > > where sc is the number of linear cells. This is fine till quadratic > elements (EDGE3) since sc < 2 but for EDGE4, and higher order > elements, this is not true anymore. Should this assert still exist or > was there an ulterior motive to placing this in the code ? Since VTK > does not support visualizing higher order elements, splitting the > elements to many linear elements and writing out the solution at the > vertices would require that this condition not be met. Comments ? Based on some conversations at a TACC viz workshop I gather that there aren't *any* generic visualization codes out there that properly handle higher order elements. Sad if true. Until that changes though, splitting into linear subelements is the way to go. > An alternative is that there are more n_sub_elem() (more than 2) for > higher order elements. Is this an option? Definitely; this is the right way to do it. But it's not a trivial option, unfortunately. IIRC we currently do subdivision on an adhoc, format-by-format basis in the output codes. What we really ought to have is an Elem method that creates a vector<Elem> with its own subdivision done, then write those subelements to file in the *IO classes. --- Roy |
From: Vijay S. M. <vi...@gm...> - 2010-10-13 17:48:50
|
Roy I am almost done testing both 1 and 2 dimensional elements (only edges and quads for now). I have the placeholders for Hexes but need to decide a suitable numbering before I can do anything there. I am not entirely sure about the way to go for the higher-order output. Writing out multiple linear elements is sensible but the call to elem->connectivity in vtkIO is confusing. There is only one call to obtain the connectivity for an element and this is with a '0' index for the first argument. This means for higher order elements (even for second order QUAD), only the first sub-element will be written. Is this correct ? I don't see any check for sub_elem and a loop over these sub elements anywhere. Should I add this to enable higher order output as linear elements or did I misunderstand the code ? I do need to check my embedding matrix for the quads again but once that is done, the code should be in a good shape for a patch. Hopefully I'll find enough time to get back to this by the weekend so that anyone interested can actually test it out on different problems. I'll keep you guys updated if I have any other issues. VIjay On Wed, Oct 13, 2010 at 11:47 AM, Roy Stogner <roy...@ic...> wrote: > > I'm jumping into this very late; a couple comments: > > On Mon, 4 Oct 2010, Vijay S. Mahadevan wrote: > >>> For higher-order elements the embedding matrices will be enormous, not >>> sure we want to mess with these if we don't have to... >> >> Are you saying that higher order elements dont need the embedding >> matrix defined ? Or am I understanding you wrongly. > > I think John was saying that higher order elements wouldn't need the > embedding matrix defined if they were limited to lower order geometry. > >> I am going to try to write a matlab script that will evaluate the >> basis functions at a given point and that should hopefully minimize >> all the work for creating these matrices. As long as I specify the >> right coordinates in the reference element, the embedding matrix >> should be easy to evaluate. Do you think there is an easier way ? > > I think this is probably the way to go. > >> I found another quirk in the EDGE* codes. There is an assert in >> connectivity() routine as follows: >> >> libmesh_assert (sc < this->n_sub_elem()); >> >> where sc is the number of linear cells. This is fine till quadratic >> elements (EDGE3) since sc < 2 but for EDGE4, and higher order >> elements, this is not true anymore. Should this assert still exist or >> was there an ulterior motive to placing this in the code ? Since VTK >> does not support visualizing higher order elements, splitting the >> elements to many linear elements and writing out the solution at the >> vertices would require that this condition not be met. Comments ? > > Based on some conversations at a TACC viz workshop I gather that there > aren't *any* generic visualization codes out there that properly > handle higher order elements. Sad if true. Until that changes > though, splitting into linear subelements is the way to go. > >> An alternative is that there are more n_sub_elem() (more than 2) for >> higher order elements. Is this an option? > > Definitely; this is the right way to do it. But it's not a trivial > option, unfortunately. IIRC we currently do subdivision on an adhoc, > format-by-format basis in the output codes. What we really ought to > have is an Elem method that creates a vector<Elem> with its own > subdivision done, then write those subelements to file in the *IO > classes. > --- > Roy > |
From: Vijay S. M. <vi...@gm...> - 2010-11-15 20:02:47
|
All, I'm terribly sorry for not keeping you updated on this effort. I got side tracked with other things and haven't been able to get back to it until now. I will focus on getting the embedding matrices written out so that the patch will be almost complete. Hopefully, these higher order elements will make it in the next release after enough testing. I'll send you a patch in the coming days. Vijay On Wed, Oct 13, 2010 at 12:48 PM, Vijay S. Mahadevan <vi...@gm...> wrote: > Roy I am almost done testing both 1 and 2 dimensional elements (only > edges and quads for now). I have the placeholders for Hexes but need > to decide a suitable numbering before I can do anything there. > > I am not entirely sure about the way to go for the higher-order > output. Writing out multiple linear elements is sensible but the call > to elem->connectivity in vtkIO is confusing. There is only one call to > obtain the connectivity for an element and this is with a '0' index > for the first argument. This means for higher order elements (even for > second order QUAD), only the first sub-element will be written. Is > this correct ? I don't see any check for sub_elem and a loop over > these sub elements anywhere. Should I add this to enable higher order > output as linear elements or did I misunderstand the code ? > > I do need to check my embedding matrix for the quads again but once > that is done, the code should be in a good shape for a patch. > Hopefully I'll find enough time to get back to this by the weekend so > that anyone interested can actually test it out on different problems. > I'll keep you guys updated if I have any other issues. > > VIjay > > On Wed, Oct 13, 2010 at 11:47 AM, Roy Stogner <roy...@ic...> wrote: >> >> I'm jumping into this very late; a couple comments: >> >> On Mon, 4 Oct 2010, Vijay S. Mahadevan wrote: >> >>>> For higher-order elements the embedding matrices will be enormous, not >>>> sure we want to mess with these if we don't have to... >>> >>> Are you saying that higher order elements dont need the embedding >>> matrix defined ? Or am I understanding you wrongly. >> >> I think John was saying that higher order elements wouldn't need the >> embedding matrix defined if they were limited to lower order geometry. >> >>> I am going to try to write a matlab script that will evaluate the >>> basis functions at a given point and that should hopefully minimize >>> all the work for creating these matrices. As long as I specify the >>> right coordinates in the reference element, the embedding matrix >>> should be easy to evaluate. Do you think there is an easier way ? >> >> I think this is probably the way to go. >> >>> I found another quirk in the EDGE* codes. There is an assert in >>> connectivity() routine as follows: >>> >>> libmesh_assert (sc < this->n_sub_elem()); >>> >>> where sc is the number of linear cells. This is fine till quadratic >>> elements (EDGE3) since sc < 2 but for EDGE4, and higher order >>> elements, this is not true anymore. Should this assert still exist or >>> was there an ulterior motive to placing this in the code ? Since VTK >>> does not support visualizing higher order elements, splitting the >>> elements to many linear elements and writing out the solution at the >>> vertices would require that this condition not be met. Comments ? >> >> Based on some conversations at a TACC viz workshop I gather that there >> aren't *any* generic visualization codes out there that properly >> handle higher order elements. Sad if true. Until that changes >> though, splitting into linear subelements is the way to go. >> >>> An alternative is that there are more n_sub_elem() (more than 2) for >>> higher order elements. Is this an option? >> >> Definitely; this is the right way to do it. But it's not a trivial >> option, unfortunately. IIRC we currently do subdivision on an adhoc, >> format-by-format basis in the output codes. What we really ought to >> have is an Elem method that creates a vector<Elem> with its own >> subdivision done, then write those subelements to file in the *IO >> classes. >> --- >> Roy >> > |
From: Roy S. <roy...@ic...> - 2010-11-15 20:07:41
|
On Mon, 15 Nov 2010, Vijay S. Mahadevan wrote: > I'm terribly sorry for not keeping you updated on this effort. I got > side tracked with other things and haven't been able to get back to it > until now. I will focus on getting the embedding matrices written out > so that the patch will be almost complete. Hopefully, these higher > order elements will make it in the next release after enough testing. > I'll send you a patch in the coming days. No stress. The delay was actually pretty convenient; even with lots of local testing I'd have been wary of putting a large new feature in right before releasing 0.7.0. Now that that's freshly out and only receiving backported bugfixes (hmm... I should announce 0.7.0.3), it's the perfect time for us to all start breaking everything again. ;-) --- Roy |