RE: [Libmesh-devel] Re: gmv_io

[John P. <pet...@cf...>]

KIRK, BENJAMIN (JSC-EG) (NASA) writes:
 > The EquationSystems class provides parameters, which are a mapping f=
rom an
 > arbitrary string to a floating-point value... See example 2.  Do you=
 think
 > that would work?  The GMVIO implementation can check for a relevant
 > parameter and use it if it is present.
 >=20
 > I would be hesitant to add more to the MeshIO interface.  My thought=
s are
 > that it should remain as simple as possible, essentially only provid=
ing a
 > read() and write() method.  The reason for this is that the MeshIO c=
lass is
 > kinda the bare minimum functionality we expect from *any* I/O
 > implementation...  (Even as it stands it is a bit too much.  What is=
 really
 > needed it MeshInput & MeshOutput which implement read() and write(),=

 > respectively.  MeshIO could simply inherit from both of these.)
 >=20
 > If you need to extend the interface I'd do it to the GMVIO class.  T=
he idea
 > is that you only will call this extended interface when you *know* y=
ou are
 > dealing with GMV output, hence you will instantiate a GMVIO object d=
irectly.
 > This is opposed to the general case where you conceivably deal with =
a MeshIO
 > object and have no idea what implementation is actually being used.
 >=20
 > Thoughts?


I would agree with Ben on that one.  It seems our new mantra is "less i=
s more"
as far as interfaces are concerned.  BTW, I like the Idea of the MeshIn=
put and
MeshOutput classes, similar to the iostreams.  In that design, who hold=
s the
reference to the mesh? :)

Can GMV do something special if you tell it that a certain variable is =
a
velociyt?  It'd be nice not to have to manually build the vector in GMV=
 every time.

-John



 > -----Original Message-----
 > From: lib...@li...
 > [mailto:lib...@li...] On Behalf Of Mart=
in L=FCthi
 > Sent: Tuesday, November 16, 2004 4:08 PM
 > To: Benjamin S. Kirk
 > Cc: libmesh-devel
 > Subject: [Libmesh-devel] Re: gmv_io
 >=20
 >=20
 > Hi Ben
 >=20
 > Benjamin S. Kirk writes:
 >=20
 > After trying for a while to do what you propose above, I quit, somew=
hat
 > frustrated. Now I see that you invested quite a bit of work into cle=
aning up
 > the new implementation. Thanks! It works great, at least for me.
 >=20
 > Now some more points (this is why I CC this to the list):
 >=20
 > o I would like to provide additional information to the write method=

 >   of the mesh_io class (and specifically to gmv_io). This includes
 >   information on solution time, which variables are velocities ...
 >  =20
 > o To do this I propose to add a write_equation_systems method call
 >   with a vector of pairs of strings. If a specific IO code knows how=

 >   to handle that list, fine, otherwise, it gets ignored.
 >=20
 >   For example in gmv_io, one would check for the "solution_time"
 >   keyword in the list, and output the corresponding field "probtime"=
.
 >   Or one could check which variable names qualify as velocity and
 >   output them as "velocity".
 >=20
 > o This enhancement would require to add an additional function call =
to
 >   all the mesh_io write* functions, and also in all implementations.=
=20
 >=20
 > WDYT
 >=20
 > Best, Martin
 >=20
 > --=20
 > Martin L=FCthi              University of Alaska, Fairbanks
 > Dr. sc. nat.              tel: +1 (907) 474 7691
 >                           fax: +1 (907) 474 7290
 >                           mel: lu...@gi...
 >=20
 > http://gi.alaska.edu/~luthi/