<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:
>> if (need_inf_elem && !built_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
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.
>>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_
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
A factory _should_ let you get around that by associating strings with
objects. You can then do this:
LinearSolverInterface *lsi =
(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'?)