From: Kirk, B. (JSC-EG) <Ben...@na...> - 2009-02-10 19:39:44
|
I'll dump some quick thoughts and then follow up some more later.... From my perspective, the current DofObjects are too heavy. This especially true in the common case of lagrange elements, as the dof indexing is never used for elements. So I am hesitant to add anything... At the same time, there is no way the library can pack arbitrary data for communication without user help... What I was thinking as an alternative is - gasp - templates. Specifically, temnplating on the DofObjectType used for both Elem an Nodes. The UnstruturedMesh is then a typedef for UnstructuredMeshImpl<DofObject,DofObject> or something. But the benefit is that the user is free to implement derived DofObject types which store whatever, implement additiona packing/unpacking as required, then use UnstructuredMeshImpl<FatDofObject, SkinnyDofObject> or whatever... Thoughts? Let the stone throwing begin... -Ben ----- Original Message ----- From: Vijay S. Mahadevan <vi...@gm...> To: lib...@li... <lib...@li...> Sent: Tue Feb 10 13:21:13 2009 Subject: [Libmesh-users] Material number and other tags. Hi guys, I am in a pickle here. I originally had my custom implementation of associating tags with elements and nodes to maintain the material numbers and other physics relevant information. But then, I modified my code to actually attach the material number information to the sbd_id in Elem. I remember reading that most of you follow this to identify the material corresponding to a finite element. I have a complication due to this: I have more than 255 materials and since _sbd_id is unsigned char, this leads to garbage. On the other hand, I do not want to go back to mesh_data usage either since it is messy and I need to propagate information based on refinement and coarsening. As a solution, I was wondering whether it would make sense to add a std::vector<objects> for every element and node. Of course, by default these will be empty to save resources. This way, the user controls what tags to associate with every element and thereby helps the physics calculations in a better way. If you think this is not the way to go and then do pass on your comments. If you have better ideas that you are using already or want to try out, I would love to hear that too. Thanks in advance. Vijay ------------------------------------------------------------------------------ Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com _______________________________________________ Libmesh-users mailing list Lib...@li... https://lists.sourceforge.net/lists/listinfo/libmesh-users |
From: Roy S. <roy...@ic...> - 2009-02-10 20:04:09
|
On Tue, 10 Feb 2009, Kirk, Benjamin (JSC-EG) wrote: > I'll dump some quick thoughts and then follow up some more later.... > >> From my perspective, the current DofObjects are too heavy. This >> especially true in the common case of lagrange elements, as the >> dof indexing is never used for elements. So I am hesitant to add >> anything... > > At the same time, there is no way the library can pack arbitrary > data for communication without user help... > > > What I was thinking as an alternative is - gasp - templates. > Specifically, temnplating on the DofObjectType used for both Elem an > Nodes. The UnstruturedMesh is then a typedef for > UnstructuredMeshImpl<DofObject,DofObject> or something. > > But the benefit is that the user is free to implement derived > DofObject types which store whatever, implement additiona > packing/unpacking as required, then use > UnstructuredMeshImpl<FatDofObject, SkinnyDofObject> or whatever... > > Thoughts? Seems like a lot of complication to save what, a couple dozen bytes per element? Don't forget we're also going to end up needing to recompile Elem<SkinnyDofObject>, Node<FatDofObject>, Pyramid5<SkinnyDofObject> ... At that point, if you're using templates, are there going to be any .C files left in the library? We could make Elem derive from ElemDofObject and Node derive from NodeDofObject, and typedef those to the current implementation. That wouldn't require quite such sweeping changes, although it would still require a configure/recompile for any user who wanted to create something like a "first order lagrange only" version of libMesh. --- Roy |
From: Kirk, B. (JSC-EG) <Ben...@na...> - 2009-02-10 20:30:03
|
>> >> But the benefit is that the user is free to implement derived >> DofObject types which store whatever, implement additiona >> packing/unpacking as required, then use >> UnstructuredMeshImpl<FatDofObject, SkinnyDofObject> or whatever... >> >> Thoughts? > > Seems like a lot of complication to save what, a couple dozen bytes > per element? Don't forget we're also going to end up needing to > recompile Elem<SkinnyDofObject>, Node<FatDofObject>, > Pyramid5<SkinnyDofObject> ... At that point, if you're using > templates, are there going to be any .C files left in the library? The savings with 0 variables will be minor, but as you add variables the current DofObject allocates storage to keep track of how many components each variable has on the object, and that means for 20 variables with lagrange elements you are storing a 20-length vector just to keep track of no variables for Elements... Really, though, I had been thinking of this for another reason, and saw Vijay's need as another possible use. Consider the aforementioned case, where I have 20 variables of the same type. Our current DofObject is very wasteful for this case, indeed as is all of DofMap. At a minimum a BlockDofObject or something seems useful, but how to do that without templates??? > We could make Elem derive from ElemDofObject and Node derive from > NodeDofObject, and typedef those to the current implementation. That > wouldn't require quite such sweeping changes, although it would still > require a configure/recompile for any user who wanted to create > something like a "first order lagrange only" version of libMesh. (you'd get second order too...) ...and that is how you do it without templates. I like the idea of EmptyDofObject, DofObject, and BlockDofObject, where NodeDofObject and ElemDofObject are both typedef'ed to DofObject, but redefineable at configure time. I still maintain that the library *cannot* implement std::vector<Whatever> inside the DofObject without user cooperation (at least in the case of parallel redistribution, restart, etc...) But as for addressing only the subdomain id type, the typdedef is certainly the way to go. -Ben |
From: Roy S. <roy...@ic...> - 2009-02-10 20:50:07
|
On Tue, 10 Feb 2009, Kirk, Benjamin (JSC-EG) wrote: > The savings with 0 variables will be minor, but as you add variables the > current DofObject allocates storage to keep track of how many components > each variable has on the object, and that means for 20 variables with > lagrange elements you are storing a 20-length vector just to keep track of > no variables for Elements... Right, but as you point out we're also storing a 20-length vector on each Node just to remind ourselves that yes, 20 variables with the same FEType all have the same relative indexing. Get rid of those 19 superfluous values and you'll get 19 of the other 20 for free. > Consider the aforementioned case, where I have 20 variables of the same > type. Our current DofObject is very wasteful for this case, indeed as is > all of DofMap. At a minimum a BlockDofObject or something seems useful, but > how to do that without templates??? Once you've got a BlockDofObject working correctly, why would you want to add a templated option to use the less efficient old DofObject? Just call the new one DofObject and you're done. > I still maintain that the library *cannot* implement std::vector<Whatever> > inside the DofObject without user cooperation (at least in the case of > parallel redistribution, restart, etc...) Definitely. --- Roy |
From: Kirk, B. (JSC-EG) <Ben...@na...> - 2009-02-10 21:00:16
|
> Once you've got a BlockDofObject working correctly, why would you want > to add a templated option to use the less efficient old DofObject? > Just call the new one DofObject and you're done. Well, I can still see the use for an EmptyDofObject... The problem I see with only a blocked DofObject is how to still do mixed element simulations properly, e.g. Taylor-Hood and friends. At any rate, it is certainly something we need, and just as importantly, to handle the associated algorithmic savings in the DofMap. -Ben |
From: Roy S. <roy...@ic...> - 2009-02-10 21:19:13
|
On Tue, 10 Feb 2009, Kirk, Benjamin (JSC-EG) wrote: >> Once you've got a BlockDofObject working correctly, why would you want >> to add a templated option to use the less efficient old DofObject? >> Just call the new one DofObject and you're done. > > Well, I can still see the use for an EmptyDofObject... Yeah, you'll sometimes get a little extra savings there. I still don't think it's worth an invasive new template layer, although I at least won't kick and scream if you want to implement NodeDofObject and ElemDofObject typedefs. > The problem I see with only a blocked DofObject is how to still do mixed > element simulations properly, e.g. Taylor-Hood and friends. The catch is that you'd need to save more global mapping data (e.g. variable N is of fe_type M, the first index of variable N is J). This means that we'd have to break the DofObject API by adding const DofMap& arguments to n_vars(), n_dofs(), n_comp(), dof_number(), etc. --- Roy |
From: Vijay S. M. <vi...@gm...> - 2009-02-11 23:06:23
Attachments:
subdomain_id_type patch.patch
|
Hi all, Attached is the patch for changing the subdomain id to a typedef'd unsigned int from unsigned char. It fits my needs well and have not had problems dealing with 1000's of materials now. The typedef is defined on top of Elem.h. Do have a look at the patch and if everything looks good (conventions and definition placement), do commit this. One more question though. It occurred to me that while doing this, in parallel, if you partition according to subdomain_id's it will lead to bad partitioning in my case. This is because I could sometimes have 'almost' random distribution of materials and since I am now maintaining material number with subdomain_id, I worry whether this will come back to bite me later. Do you see this to be a problem ? Vijay PS: My original libmesh sources have quite a few changes that do not exist in libmesh code repository and I had to weed out changes that you will not be interested here. So if anything seems out of place, feel free to remove it. On Tue, Feb 10, 2009 at 3:19 PM, Roy Stogner <roy...@ic...> wrote: > > On Tue, 10 Feb 2009, Kirk, Benjamin (JSC-EG) wrote: > >>> Once you've got a BlockDofObject working correctly, why would you want >>> to add a templated option to use the less efficient old DofObject? >>> Just call the new one DofObject and you're done. >> >> Well, I can still see the use for an EmptyDofObject... > > Yeah, you'll sometimes get a little extra savings there. I still > don't think it's worth an invasive new template layer, although I > at least won't kick and scream if you want to implement NodeDofObject > and ElemDofObject typedefs. > >> The problem I see with only a blocked DofObject is how to still do mixed >> element simulations properly, e.g. Taylor-Hood and friends. > > The catch is that you'd need to save more global mapping data (e.g. > variable N is of fe_type M, the first index of variable N is J). This > means that we'd have to break the DofObject API by adding const > DofMap& arguments to n_vars(), n_dofs(), n_comp(), dof_number(), etc. > --- > Roy > > ------------------------------------------------------------------------------ > Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) > software. With Adobe AIR, Ajax developers can use existing skills and code to > build responsive, highly engaging applications that combine the power of local > resources and data with the reach of the web. Download the Adobe AIR SDK and > Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com > _______________________________________________ > Libmesh-devel mailing list > Lib...@li... > https://lists.sourceforge.net/lists/listinfo/libmesh-devel > |
From: Roy S. <roy...@ic...> - 2009-02-11 22:21:41
|
On Wed, 11 Feb 2009, Vijay S. Mahadevan wrote: > Do have a look at the patch and if everything looks good (conventions > and definition placement), do commit this. Looks good so far; let me test a couple things and I'll commit it. > One more question though. It occurred to me that while doing this, in > parallel, if you partition according to subdomain_id's it will lead to > bad partitioning in my case. Do we base our partitioning on subdomain ids at all? I know most of our built-in partitioners don't. Even with ParMETIS, I was under the impression that we handed the element connectivity graph to them but didn't give them any subdomain information. > PS: My original libmesh sources have quite a few changes that do not > exist in libmesh code repository and I had to weed out changes that > you will not be interested here. So if anything seems out of place, > feel free to remove it. I didn't see anything in need of removal. If you're having to fork the libMesh code, though, it's possible that one of us is doing something counterproductive - either us for not being as easily extensible as we should be or you for not writing extensions that are modular enough to be independent of or acceptable back in the main library. Neither of us may have time to fix those situations, but it's still sad - if you're significantly modifying the library but still keeping up with our changes, the svn conflicts must be a bear. --- Roy |
From: Roy S. <roy...@ic...> - 2009-02-11 22:21:42
|
On Wed, 11 Feb 2009, Roy Stogner wrote: > On Wed, 11 Feb 2009, Vijay S. Mahadevan wrote: > >> Do have a look at the patch and if everything looks good (conventions >> and definition placement), do commit this. > > Looks good so far; let me test a couple things and I'll commit it. I would like to hear your and Ben's views on what the default should be; it's probably inconvenient for you to keep it switched to unsigned int if we're still using unsigned char. But, thanks to structure padding, an unsigned short or unsigned int is likely to take up 4 more bytes per element, and Ben sounds quite concerned about memory use lately. Also, I need to add some comment up at the definition about what types are allowed; it looks like PackedElem means that (at least in parallel) we're still limited to types that can static_cast to and from int successfully, and the I/O classes probably restrict us to types that can operator= to and from int successfully. I guess that's not a *bad* thing; it'll dissuade people from making subdomain ids into a bitset or a custom class or something else that'll end up backfiring on them. --- Roy |
From: Vijay S. M. <vi...@gm...> - 2009-02-12 03:35:06
|
> I would like to hear your and Ben's views on what the default should > be; it's probably inconvenient for you to keep it switched to unsigned > int if we're still using unsigned char. That is interesting. I would think that since unsigned char suited for most users needs till now, that should be the default. But if a user needs to use more material ids based on subdomain id, then he should have an easy way to change it. Refer to my previous email about this. May be typedefing would be straight forward enough for a user to change as long as he knows where to find it... What do you think ?! On Wed, Feb 11, 2009 at 4:01 PM, Roy Stogner <roy...@ic...> wrote: > > On Wed, 11 Feb 2009, Roy Stogner wrote: > >> On Wed, 11 Feb 2009, Vijay S. Mahadevan wrote: >> >>> Do have a look at the patch and if everything looks good (conventions >>> and definition placement), do commit this. >> >> Looks good so far; let me test a couple things and I'll commit it. > > I would like to hear your and Ben's views on what the default should > be; it's probably inconvenient for you to keep it switched to unsigned > int if we're still using unsigned char. But, thanks to structure > padding, an unsigned short or unsigned int is likely to take up 4 more > bytes per element, and Ben sounds quite concerned about memory use > lately. > > Also, I need to add some comment up at the definition about what types > are allowed; it looks like PackedElem means that (at least in > parallel) we're still limited to types that can static_cast to and > from int successfully, and the I/O classes probably restrict us to > types that can operator= to and from int successfully. I guess that's > not a *bad* thing; it'll dissuade people from making subdomain ids > into a bitset or a custom class or something else that'll end up > backfiring on them. > --- > Roy > |
From: Roy S. <roy...@ic...> - 2009-02-12 00:02:28
|
On Wed, 11 Feb 2009, Roy Stogner wrote: > On Wed, 11 Feb 2009, Vijay S. Mahadevan wrote: > >> Do have a look at the patch and if everything looks good (conventions >> and definition placement), do commit this. > > Looks good so far; let me test a couple things and I'll commit it. There was one spot you missed that should have been converted to subdomain_id, and one spot you converted that shouldn't have been (although I'm not surprised, it was in a subdomain-handling function and tricked me too before I ran a class object test through it). I also got rid of some of those static casts where a copy will do just as well, just for aesthetics' sake. I also moved the typedef to a new header file, to allow mesh_tools.h to continue to get away with forward declaring Elem. I left the typedef as unsigned char for now; if you and Ben want to change the default to unsigned int that's fine with me. It's all committed to SVN now. --- Roy |
From: Vijay S. M. <vi...@gm...> - 2009-02-12 03:30:05
|
> There was one spot you missed that should have been converted to > subdomain_id, and one spot you converted that shouldn't have been > (although I'm not surprised, it was in a subdomain-handling function > and tricked me too before I ran a class object test through it). Roy, just curious as to which source file this was happening. It is much easier for me to make the change in to my source directly rather than updating and merging the code along with my existing changes. > I left the typedef as unsigned char for now; if you and Ben want to > change the default to unsigned int that's fine with me. I guess asking to make this configurable with ./configure might be too much to ask. But is there some way to define a flag or something to make this change with a user defined header. Perhaps something with preprocessors (#ifdefs) ? Or does it not make sense ? I propose this because if tomorrow you change some other property in Elem and typedef it, I would like it to be easy enough to change the definition to fit my needs. If there is no clean way to do this, do not worry about it. As long future changes are typedef'd also, I can modify it accordingly. Vijay On Wed, Feb 11, 2009 at 6:02 PM, Roy Stogner <roy...@ic...> wrote: > > On Wed, 11 Feb 2009, Roy Stogner wrote: > >> On Wed, 11 Feb 2009, Vijay S. Mahadevan wrote: >> >>> Do have a look at the patch and if everything looks good (conventions >>> and definition placement), do commit this. >> >> Looks good so far; let me test a couple things and I'll commit it. > > There was one spot you missed that should have been converted to > subdomain_id, and one spot you converted that shouldn't have been > (although I'm not surprised, it was in a subdomain-handling function > and tricked me too before I ran a class object test through it). I > also got rid of some of those static casts where a copy will do just > as well, just for aesthetics' sake. > > I also moved the typedef to a new header file, to allow mesh_tools.h > to continue to get away with forward declaring Elem. > > I left the typedef as unsigned char for now; if you and Ben want to > change the default to unsigned int that's fine with me. > > It's all committed to SVN now. > --- > Roy > |
From: Roy S. <roy...@ic...> - 2009-02-12 03:43:04
|
On Wed, 11 Feb 2009, Vijay S. Mahadevan wrote: >> There was one spot you missed that should have been converted to >> subdomain_id, and one spot you converted that shouldn't have been >> (although I'm not surprised, it was in a subdomain-handling function >> and tricked me too before I ran a class object test through it). > > Roy, just curious as to which source file this was happening. It is > much easier for me to make the change in to my source directly rather > than updating and merging the code along with my existing changes. IIRC The spot you didn't convert and should have was in mesh_tools; the spot you did but shouldn't have was in boundary_info. But you might just want to do an update and merge; even if you do that conversion and unconversion by hand, the biggest difference from your patch was moving the typedef to a separate header. And if you're getting conflicts from new merges, that's a reason to do them more frequently, not less; the conflicts you get end up being less frequent and easier to resolve. >> I left the typedef as unsigned char for now; if you and Ben want to >> change the default to unsigned int that's fine with me. > > I guess asking to make this configurable with ./configure might be too > much to ask. I'll happily accept a patch, but won't have time to write it myself for a while. > But is there some way to define a flag or something to make this > change with a user defined header. Perhaps something with > preprocessors (#ifdefs) ? Or does it not make sense ? I propose this > because if tomorrow you change some other property in Elem and > typedef it, I would like it to be easy enough to change the > definition to fit my needs. If there is no clean way to do this, do > not worry about it. As long future changes are typedef'd also, I > can modify it accordingly. I'm not sure I understand - now that we've got things down into one typedef that's not even in elem.h, that's about as easy for you to maintain as it'll get without a configure test. And yes, for any future type changes (boundary_id, I'm looking at you) we'll wrap them in a typedef; hunting through the library for every instance of a certain sort of index is too tedious to risk having to do it twice. --- Roy |
From: Vijay S. M. <vi...@gm...> - 2009-02-10 20:46:40
|
Alright. First, I'll make the change of type for sbd_id to unsigned int in Elem.h and all other relevant files. I will include a patch of this once I have tested that it works with my code. And my next step would be to see if I can do something with MeshData. Since no one is using this, from what I gather, I will see if this object can be made useful again. Ben, if std::vector<blah> is not the way to go, then the idea behind propagating MeshData's structure would also fall prey to all the same issues as having a generic container in Elem. But this is how the interface is already defined for MeshData ! The would it be elegant to do something like what Roy suggested. Give a pointer to an abstract base class with serialization functions for different mesh formats and attribute computation by user based on child attributes during coarsenings ? I am just trying to figure out what would be more natural and to avoid pitfalls that Derek pointed out. Anyway, thanks for the ideas guys ! I shall mail again later with a patch and hopefully more ideas... On Tue, Feb 10, 2009 at 2:29 PM, Kirk, Benjamin (JSC-EG) <Ben...@na...> wrote: >>> >>> But the benefit is that the user is free to implement derived >>> DofObject types which store whatever, implement additiona >>> packing/unpacking as required, then use >>> UnstructuredMeshImpl<FatDofObject, SkinnyDofObject> or whatever... >>> >>> Thoughts? >> >> Seems like a lot of complication to save what, a couple dozen bytes >> per element? Don't forget we're also going to end up needing to >> recompile Elem<SkinnyDofObject>, Node<FatDofObject>, >> Pyramid5<SkinnyDofObject> ... At that point, if you're using >> templates, are there going to be any .C files left in the library? > > > The savings with 0 variables will be minor, but as you add variables the > current DofObject allocates storage to keep track of how many components > each variable has on the object, and that means for 20 variables with > lagrange elements you are storing a 20-length vector just to keep track of > no variables for Elements... > > Really, though, I had been thinking of this for another reason, and saw > Vijay's need as another possible use. > > Consider the aforementioned case, where I have 20 variables of the same > type. Our current DofObject is very wasteful for this case, indeed as is > all of DofMap. At a minimum a BlockDofObject or something seems useful, but > how to do that without templates??? > >> We could make Elem derive from ElemDofObject and Node derive from >> NodeDofObject, and typedef those to the current implementation. That >> wouldn't require quite such sweeping changes, although it would still >> require a configure/recompile for any user who wanted to create >> something like a "first order lagrange only" version of libMesh. > > (you'd get second order too...) > > ...and that is how you do it without templates. I like the idea of > > EmptyDofObject, DofObject, and BlockDofObject, where NodeDofObject and > ElemDofObject are both typedef'ed to DofObject, but redefineable at > configure time. > > I still maintain that the library *cannot* implement std::vector<Whatever> > inside the DofObject without user cooperation (at least in the case of > parallel redistribution, restart, etc...) > > But as for addressing only the subdomain id type, the typdedef is certainly > the way to go. > > -Ben > > > > > > > ------------------------------------------------------------------------------ > Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) > software. With Adobe AIR, Ajax developers can use existing skills and code to > build responsive, highly engaging applications that combine the power of local > resources and data with the reach of the web. Download the Adobe AIR SDK and > Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com > _______________________________________________ > Libmesh-devel mailing list > Lib...@li... > https://lists.sourceforge.net/lists/listinfo/libmesh-devel > |
From: Kirk, B. (JSC-EG) <Ben...@na...> - 2009-02-10 20:53:42
|
> Alright. First, I'll make the change of type for sbd_id to unsigned > int in Elem.h and all other relevant files. I will include a patch of > this once I have tested that it works with my code. To be clear, you mean a change to typedef unsigned short int subdoman_id_t; subdomain_id_t _sbd_id; or something like that? > Ben, if std::vector<blah> is not the way to go, then the idea behind > propagating MeshData's structure would also fall prey to all the same > issues as having a generic container in Elem. But this is how the > interface is already defined for MeshData ! The would it be elegant to > do something like what Roy suggested. This is really a semantic issue. I was thinking that my notional 'FatDofObject' would contain something like this std::vector<blah>, or a blah itself, or whatever... What I do not want to do is throw an unused vector in the base DofObject (or Elem), which is why I suggested the templates. But for a lot of reasons Roy's typedef makes more sense. -Ben |
From: Vijay S. M. <vi...@gm...> - 2009-02-10 21:16:15
|
> To be clear, you mean a change to > > typedef unsigned short int subdoman_id_t; > > subdomain_id_t _sbd_id; > > or something like that? > Yes. I do intend to define subdomain_id_type as a unsigned int type. All references to _sbd_id with actually use this type instead of the hard-coded unsigned char. So if need be, for someone's requirement, if unsigned char is good enough, you could just change it in one location and things will work like they do now. > This is really a semantic issue. I was thinking that my notional > 'FatDofObject' would contain something like this std::vector<blah>, or a > blah itself, or whatever... What I do not want to do is throw an unused > vector in the base DofObject (or Elem), which is why I suggested the > templates. But for a lot of reasons Roy's typedef makes more sense. > I was not talking about the typedefs here. I quoted Roy about the base data container class with user implementation for serializing in to different formats, and user implementation to create the coarser object's attributes based on children's attributes. This can be implemented quite nicely IMO. But like Derek suggested, the user will have something to do with the prolongation/restriction algorithm so to speak (in terms of propagating this attribute data) and I wonder how big an overhead in memory this might introduce than the original std::vector<blah> method with all its inherent imperfections. Btw, like I mentioned before, MeshData does use std::vector<blah> as its defacto way of attaching tags to DofObjects now. Anyway, I will think more on this and get back to you later today. Vijay |
From: John P. <pet...@cf...> - 2009-02-10 20:59:15
|
On Tue, Feb 10, 2009 at 2:46 PM, Vijay S. Mahadevan <vi...@gm...> wrote: > Alright. First, I'll make the change of type for sbd_id to unsigned > int in Elem.h and all other relevant files. I will include a patch of > this once I have tested that it works with my code. > Not to look a gift horse in the mouth, but would you mind doing exactly what Roy suggested, namely as well start by fixing this one. Find everywhere a subdomain id is > being used, change it from unsigned char to subdomain_id_t, add a > "typedef unsigned char subdomain_id_t;" to an appropriate header, Thanks! -- John |
From: Vijay S. M. <vi...@gm...> - 2009-02-10 20:12:21
|
Hi Ben, Although the idea sounds good to me at first glance, I really would not want to inherit from one of the core objects such as DofObject and end up messing something critical in my simulation. I had rather have my needs as attributes or tags that can be attached and removed on Elem's and Node's or just DofObject's. Another level of inheritance just leads to more complexity. My 2 cents. Vijay On Tue, Feb 10, 2009 at 1:39 PM, Kirk, Benjamin (JSC-EG) <Ben...@na...> wrote: > I'll dump some quick thoughts and then follow up some more later.... > > From my perspective, the current DofObjects are too heavy. This especially true in the common case of lagrange elements, as the dof indexing is never used for elements. So I am hesitant to add anything... > > At the same time, there is no way the library can pack arbitrary data for communication without user help... > > > What I was thinking as an alternative is - gasp - templates. Specifically, temnplating on the DofObjectType used for both Elem an Nodes. The UnstruturedMesh is then a typedef for UnstructuredMeshImpl<DofObject,DofObject> or something. > > But the benefit is that the user is free to implement derived DofObject types which store whatever, implement additiona packing/unpacking as required, then use UnstructuredMeshImpl<FatDofObject, SkinnyDofObject> or whatever... > > Thoughts? > > Let the stone throwing begin... > > -Ben > > > > > > > ----- Original Message ----- > From: Vijay S. Mahadevan <vi...@gm...> > To: lib...@li... <lib...@li...> > Sent: Tue Feb 10 13:21:13 2009 > Subject: [Libmesh-users] Material number and other tags. > > Hi guys, > > I am in a pickle here. I originally had my custom implementation of > associating tags with elements and nodes to maintain the material > numbers and other physics relevant information. But then, I modified > my code to actually attach the material number information to the > sbd_id in Elem. I remember reading that most of you follow this to > identify the material corresponding to a finite element. > > I have a complication due to this: I have more than 255 materials and > since _sbd_id is unsigned char, this leads to garbage. On the other > hand, I do not want to go back to mesh_data usage either since it is > messy and I need to propagate information based on refinement and > coarsening. > > As a solution, I was wondering whether it would make sense to add a > std::vector<objects> for every element and node. Of course, by default > these will be empty to save resources. This way, the user controls > what tags to associate with every element and thereby helps the > physics calculations in a better way. > > If you think this is not the way to go and then do pass on your > comments. If you have better ideas that you are using already or want > to try out, I would love to hear that too. > > Thanks in advance. > Vijay > > ------------------------------------------------------------------------------ > Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) > software. With Adobe AIR, Ajax developers can use existing skills and code to > build responsive, highly engaging applications that combine the power of local > resources and data with the reach of the web. Download the Adobe AIR SDK and > Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com > _______________________________________________ > Libmesh-users mailing list > Lib...@li... > https://lists.sourceforge.net/lists/listinfo/libmesh-users > |