Re: [Libmesh-devel] Re: gmv_io

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

Martin L=FCthi wrote:
> Hi again
>=20
> ...=20
> Well, there are some problems with that. To specify the names of the
> velocity variables one would need strings, not numbers. At the moment
> I set the velocity names to mandatory strings "U", "V", "W" which
> might interfere with others uses of these letters.

Probably what is needed is more explicit support for vectors at the=20
System level.  For example, one could declare

es("flow").add_scalar("rho");
es("flow").add_vector("U");
es("flow").add_scalar("T");

or something like that.  By default the vector "U" would get components=20
"U_x", "U_y", "U_z" or some standard nomenclature.  Of course, function=20
overloading could be used to optionally specify the names of the componen=
ts:

es("flow").add_vector("U", "u", "v", "w");

comes to mind.

The main reason for this is because it better hides the dimensionality=20
of the problem from the user.  Currently the user needs an if test on=20
dimension to decide how many scalar components constitute a vector for=20
their problem...


> Also, the GMVIO class has no reference to the EquationSystems
> object. For the time being I changed the signature of
> write_ascii_new_impl to pass a reference to the EquationSystem. ATM
> this is only used to access the parameter "probtime" of the
> EquationSystem.

Yeah, by design...  There are many cases where you won't even have an=20
EquationSystems object and you want to use a MeshIO object to read/write=20
your mesh.  After all, it's not EquationSystemsIO ;-), which begs the=20
question:

Perhaps what is needed is one more level of abstraction?

template class IO<class T>;

class GMVIO<class T> : public IO<T>

Then a full specialization for GMVIO<Mesh> (essentially what we have=20
now) and GMVIO<EquationSystems> which could address more of these issues?


>  > OTOH: I think that one should be able to customize the I/O. So anoth=
er
>  > approach could be to add a std::map of parameters to the MeshInput /
>  > MeshOutput class, in a similar way as in the EquationSystems class.
>  > With such an approach the both concerns are kept seperated:
>  >=20

Note the templated approach allows you to use template specialization=20
to, uh, specialize the I/O.

> Given the discussion above, I am even more conviced that a
> std::map<std::string, std::string> would be nice to pass the values
> around. What I envision is something like
>=20
> EquationSystems equation_systems (mesh);
> //gmv_writer is initialized only once
> GMVIO gmv_writer(equation_systems);
> gmv_writer.set_parameter("velocity u") =3D "U";
> gmv_writer.set_parameter("velocity v") =3D "V";
> gmv_writer.set_parameter("velocity w") =3D "W";
> gmv_writer.set_parameter("probtime") =3D "2.0";
> // due to the incredible inflexibility of C++ strings and numbers
> // cannot be mixed, so we use strings for everything
> ...
> gmv_writer.write( filename );
>=20
...
> Here I should add that I would like it more if *all* output interface
> will one day look the same, and are exchangable. Therefore a general
> method to pass additional parameters/settings to the I/O routines is
> highly desirable. My guess is that GMV is not a special case in that
> respect.=20
>=20
> Cheers, Martin

I see your point, and in this case implementing additional methods in=20
derived classes is not really desireable...  For example, the GMVIO,=20
TecplotIO, XdrIO, and I'm sure others in the future all have the=20
binary() member indicating the user wants to write binary output.=20
Sadly, however, those members are not visible indirectly through the=20
base class.

I'll go one better than yout map<string,string> concept above...  It=20
would be nice to handle more arbitrary data types as parameters...  I=20
believe the answer is a class with some templated methods:

class Parameters
{
  template <typename T>
  T   operator () (const std::string&) const;
  T & operator () (const std::string&) const;
};


Parameters parameters;

parameters("foo") =3D     2; // integer
parameters("bar") =3D "baz"; // string

etc...

Then all that is needed is a few private maps and full specialization of=20
the member functions to implement a more general parameter handler class.

The current parameters stuff in the EquationSystems class will get=20
replaced by one of these, one could be added to the MeshIO class, the=20
Partitioners certainly could use one, etc...

What do you think?

-Ben