Re: [Libmesh-devel] Mesh::read()

[Benjamin S. K. <be...@cf...>]

<please, all read & please comment - Ben>
-----------------------------------------------------------------------------------------------------------

Daniel Dreyer wrote:

>Do you want to throw all the new feats in 0.4.1?  Not release
>0.4.1 earlier?  There is a lot in 0.4.1 already...
>

Really I'm willing to tag 0.4.1 right now, I just can't test compiling 
on all my platforms today.  As for features, I think we're set. 

>Re-including some work-around for inf_elem on np>1 procs in release
>0.4.1 is currently not necessary, i'd say.  Only say in the release
>notes, that it _temporarily_ requires a work-around (like the following)
>to simulate ifems in parallel:
>  
>
>>Mesh::prepare_for_use ()
>>{
>>   if (need_inf_elem && !built_inf_elem)
>>     this->build_inf_elem()...
>>
>>   (Same old prepare for use stuff...)
>>}
>>
>>
>>(should work for the time being...  see later discussion).
>>    
>>

OK, either way.  I'd be willing to re-include the optional parameter for 
this release, and then make significant changes once it is done.  I 
think 0.5.0 will be significantly different (in the internals) than 0.4.1.

>The idea with deriving multiple meshes from Mesh is great!
>Declutters things a lot.  Nothing to improve on your suggestion
>of the Mesh hierarchy.  Perfect.
>
>But why template the MeshIO for each Mesh? -- For the ifems,
>that's really not necessary.  As you suggested, InfMesh can
>get another constructor, where do_build_inf_elem is set,
>and InfMesh overloads read().  That's it.
>
>I guess your StructuredMesh require different read() methods.
>Still, why not template the methods instead of the whole
>class? -- The templating of MeshIO::read<StructuredMesh>()
>would be shielded from the user, since she uses
>StructuredMesh::read().
>
>  
>
That's a good suggestion.  As you point out, the issue is that Tecplot 
(and many others) provide _two_ mesh formats, one for block-structured 
meshes and another for unstructured data.  Sadly, the latter is 
typically an afterthought.  Of course, templating the specific members 
is possible, and probably the right way to go. :-)  That way all user 
code will instantiate a MeshIO object and call MeshIO::read(), 
regardless of what type of mesh they are working with.

>Templating MeshIO, and instantiating for each derived class of
>Mesh, i.e. mimicing the Mesh-hierarchy through templating MeshIO...
>Hm, don't know, doesn't feel perfect.
>  
>

I agree...

>>One side effect of doing things this way is that we can cache important
>>numbers like mesh.n_elem(), mesh.n_active_elem(), etc... each time the
>>prepare_for_use() member gets called.  This can change functions like
>>    
>>
>
>That's cool! -- Esp. for the ones who overlooked the _great_
>elem_iterators etc.
>
>  Daniel
>

Yeah, for a long time I've wanted to force the use of the elem_iterators 
by making Mesh::elem(i) private.  It would not change functionality 
_at_all_, but might piss off users coming from Matlab or C or Fortran or....

The main reason I want to do this is because, who knows... maybe in the 
future a std::vector<Elem*> will not be the right way to hold the 
elements?  Maybe a singly-linked-list??  Or something else??? 

So, there is a design decision to be made here.  Do we go for the 
ultra-cool, C++-sy way to handle things and make our lives easier, or do 
we go super-generic, 
please_use_my_library_no_matter_what_language_you_like in an attempt to 
attract more users?

(of course, i like the first option, but understand/appreciate arguments 
supporting the second...)

>P.S.: Could you please explain the use of the Factory-class
>to the more ignorant ones? :)  Why collect the build methods, when
>something like a template class with 2 params is necessary?
>
>The problem may be: want to increase user base, but templating is
>normally something that is covered in the later chapters of any C++ book
>(guess you know what i mean)...  So may offend some potential users?
>E.g.: the cgal.org software may be great, but the coding style has
>probably a steep learning curve, i'd say.
>
>  
>
A factory provides an "elegant" way of producing derived classes when 
all you really need is the functionality of the base class.  Think, for 
instance, about the Elem::build(), LinearSolverInterface::build() 
etc...  members.  Every time we add a new element type etc...  we must 
define a new enum type _and_ update the switch statement in the 
::build() members.

A factory _should_ let you get around that by associating strings with 
objects.  You can then do this:

LinearSolverInterface *lsi =
  Factory<LinearSolverInterface>::build("Petsc");

(admittedly, the syntax kinda sucks, but the enabling code behind the 
scenes is arguably simpler.)

So, the factory approach should be more extensible.  However, it 
involves map lookups based on std::strings, so it is not as fast as a 
switch statement based on enums.    For instance, we should not replace 
the efficient Elem::build() member with a Factory. 

That said, it is also a wicked pain in the ass to get  the Factory 
working on multiple platforms since it requires static initialization of 
templated types.  In short, I like the idea, but the implementation is 
lacking...  (and I don't think anything better is possible??)

>P.P.S.: Since now the Mesh is read only by proc 0, MeshData should
>also work like this i suggest.  Don't have time for this right now,
>just to keep in mind.
>  
>

I agree.  The Node::key() can also be used to eliminate the maps in the 
MeshData class.  The key() should never be used by users, but this is 
the perfect case for it in the lib...  It is an unsigned int, not 
necessarily unique (but hopefully close), associated with the node.  
Right now it is 0 for all nodes read from file, and only gets assigned a 
value for nodes built via refinement.  It could easily hold the UNV id, 
for instance...  That should remove a lot of the complications 
associated with the MeshData class, hm?

(along that theme, wouldn't it be cool if C++ provided something between 
public and private for these purposes?  maybe 'sensitive'?)