A few things about this whole thread: 1. n_subdomains is useless. I did have code to set it to the correct value when reading an Exodus mesh... but it looks like it never got checked in. The reason? As you guys have been talking about there is just no good way to keep it up to date. I actually vote to have it removed. We even do things like
2. The GMSH reader and writer just needs to read and set subdomain_id's on the elements when it reads the mesh and write them back out when you write a mesh using that format. Exodus already does this... and it should be difficult to do (sounds like Vijay or Dave might already have that code hanging around somewhere). 3. Arbitrary data (like a Parameters pointer) associated with elements is BAD. Anytime you head down this path you get yourself into trouble with refinement and coarsening. The crux of the problem is understanding how to project the data down to the refined elements or up to a coarsened one. This is the path to the darkside. Instead... associate groups of elements with subdomain_ids and key off of those to associate things like material properties etc. If you think you need arbitrary data _per element_ then I implore you to think harder about the problem. Every time someone claims that they need that kind of thing I've always been able to find a more suitable solution (for instance using an extra ExplicitSystem with a constant monomial variable defined in it to get a single constant scalar per element. The difference? There is a set way to project constant monomials up and down for refinement / coarsening....). 4. There were statements to the effect of "subdomains don't change through refinement"... that might not actually be true. If you have an imbedded material with a complex boundary (that's described through some other means... probably analytically) then you might actually modify the subdomain_id of children such that they don't match their parent's subdomain_id in cases where the parent element was lying across a material boundary... Derek On Oct 27, 2009, at 5:26 PM, Roy Stogner wrote: > > On Wed, 28 Oct 2009, Arvind Ajoy wrote: > >> I am trying to read in a simple mesh created using Gmsh, which has >> two Physical regions. I use the example programme ex1.cc to read >> the .msh file, and write it out as another .msh file, i.e ./ex1 -d 2 >> in.msh out.msh. >> >> I find that the output of ex1.cc mentions n_subdomains()=1, though >> there are two physical regions. > > Interesting... > > MeshBase::n_subdomains() has been around since 2005, when Ben added > it (presumably to Mesh, back then?). > MeshBase::set_n_subdomains() appears to be an easy accessor that Derek > added earlier this year... but other than a little overloading in the > BoundaryInfo::sync() method, I can't find anywhere that subdomain > counts are actually getting *set* rather than just copied around! > > I suppose a typical use case is for the user code to set subdomain > ids, but we do support them in Exodus, GMSH, Nemesis, and XDR I/O... > yet none of that code seems to update the total mesh id count. > > Ben, Derek, anyone else know what I'm missing? It seems as if > updating MeshBase::_n_sbd ought to be a standard part of > prepare_for_use(), but isn't... > --- > Roy > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry(R) Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart > your > developing skills, take BlackBerry mobile applications to market and > stay > ahead of the curve. Join us from November 9 - 12, 2009. Register now! > http://p.sf.net/sfu/devconference > _______________________________________________ > Libmesh-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/libmesh-devel ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ Libmesh-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-users
