[Libmesh-devel] 2nd Roadmap...

[Daniel D. <mt...@an...>]

Hi all,

i liked last years' roadmap discussion.  It helped (at least me) getting 
up-to-date with where libMesh is heading.  And i have to say, most of
what i remember from what was planned, already got implemented.  So let's
see what happened, and then proceed to future ideas, i would suggest.

Ok, i just start, though quite some of what i have to say may not be of
essential interest to all of us.  But still, i think it is worth knowing
what the others do.


COMPLETED

- infinite elements: Steffen finally got the last bug(s) out of 
  them, so that they are correct, as far as we see.  To the best of
  my knowledge, libMesh is truly the _first_ open project that features
  these elements.  May be, some creators of proprietary won't like this.
  But i consider it important to disseminate these concepts.


- complex support: with PETSc on Linux no problem.  From my experience,
  libMesh is much more portable than PETSc<complex>.   Laspack started
  in complex, but still needs work.  Ben already pointed out some weak
  points.


- equation system handling now pretty friendly.  How ex7 implements
  the frequency system i consider quite a work-horse for semi-scale
  simulations.  Cannot think of necessary extensions, right now.


TODO

- modify the EquationSystems::write and read to output the param's and
  flags, and perhaps even the additional vectors? -- When no one objects,
  will start on that soon.


- debug some of the SparseMatrix-NumericVector operations recently added.
  Uniprocessor is fine, i'd say, but parallel still gives some errors,
  from PETSc, may be due to bad initialization... or due to PETSc?


- complete the infinite elements. all the inverse mapping and the
  static shape functions are still pending.  Not really a big deal,
  i'd say.


- add a virtual bool infinite() to Elem. This will enable these
  pretty inf_elem_iterators, the ones John introduced, and will
  make this ugly FEInterface::is_InfFE_elem() redundant.


- _writing_ I-Deas universal files, possibly with results.  


- Hendrik works on Bernstein polynomials as a new instantiation for
  FE<d,FEFamily>.  After some problems it seems that it will work out.

  How about joining forces for a paper on the behavior of Bernstein 
  polynomials in:
  a) nonlinear physics: CFD (provided by cfdlab/UTexas)
  b) straight linear systems: acoustics (from MuM/TUHH)
  and, e.g., comparing to the hierarchic family already included in
  libMesh? -- This would require that you at cfdlab already wrote
  or presented something about libMesh alone, so that this
  Bernstein-publication is not the first to earn the merit of libMesh.
  I have already tought quite a bit about what would be necessary to have
  a well-rounded paper, but would like to know what you think before 
  proceeding.  -- Just let me know whether there is any interest for
  such a collaboration, and i will provide more info.
  By the way: i don't know how it works at cfdlab, but i would like to
  have things settled between the libmesh developers, _before_
  proceeding to active involvement of research advisors.  From experience, 
  a well-designed concept helps a _lot_. 


- an issue with the web page: the background picture is pretty
  neat, but with my Netscape 6.2.1, and i think also with version 4,
  the background picture not only slows down build-up of the side,
  but also scrolling.  And also the source code is generally not
  visible, since the background picture somhow jumps into foreground,
  or so.
  Don't get me wrong, it is surely cool.  And this behavior may likely
  be due to bugs in the Netscape browsers.  But i don't think that
  one can expect from every page visitor that she/he has a recently
  patched browser.  Luckily, my Professor uses IE5, so this is not
  a _real_ big issue... ;-)



POSSIBLE ADDITIONAL FEATURES

- Ben already mentioned it once:  How about giving every class an
  ::info(unsigned int processor_id=0) method?  The optional parameter
  lets getting info just from one processor, which defaults to 0.
  With the static libMesh class, i would suggest that these info methods
  simply pass a string to libMesh::cout.  And libMesh::cout can
  be changed at run-time, through command-line-options, whether it, in
  turn, prints to std::cout or to a file...  Ok, the latter would
  still go with simple pipes > or |& tee etc, but it may still be 
  nice feature.

- how about a combination of a child from SystemBase with a different
  matrix that uses PETSc's matrix-free? - With PETSc<complex> _not_
  working on HP, this is pretty out of my interest.  But may give a
  nice twist to libMesh.




Looking forward to comments


  Daniel