From: KIRK, B. (JSC-E. (NASA) <ben...@na...> - 2004-11-16 22:58:08
|
The EquationSystems class provides parameters, which are a mapping from = 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. I would be hesitant to add more to the MeshIO interface. My thoughts = are that it should remain as simple as possible, essentially only providing = a read() and write() method. The reason for this is that the MeshIO = class 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.) If you need to extend the interface I'd do it to the GMVIO class. The = idea is that you only will call this extended interface when you *know* you = are dealing with GMV output, hence you will instantiate a GMVIO object = directly. 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. Thoughts? -Ben -----Original Message----- From: lib...@li... [mailto:lib...@li...] On Behalf Of Martin = L=FCthi Sent: Tuesday, November 16, 2004 4:08 PM To: Benjamin S. Kirk Cc: libmesh-devel Subject: [Libmesh-devel] Re: gmv_io Hi Ben Benjamin S. Kirk writes: After trying for a while to do what you propose above, I quit, somewhat frustrated. Now I see that you invested quite a bit of work into = cleaning up the new implementation. Thanks! It works great, at least for me. Now some more points (this is why I CC this to the list): 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. 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". o This enhancement would require to add an additional function call to all the mesh_io write* functions, and also in all implementations.=20 WDYT Best, Martin --=20 Martin L=FCthi University of Alaska, Fairbanks Dr. sc. nat. tel: +1 (907) 474 7691 fax: +1 (907) 474 7290 mel: lu...@gi... http://gi.alaska.edu/~luthi/ ------------------------------------------------------- This SF.Net email is sponsored by: InterSystems CACHE FREE OODBMS DOWNLOAD - A multidimensional database that combines robust object and relational technologies, making it a perfect match for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8 _______________________________________________ Libmesh-devel mailing list Lib...@li... https://lists.sourceforge.net/lists/listinfo/libmesh-devel |
From: John P. <pet...@cf...> - 2004-11-16 23:24:34
|
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/ |
From: <lu...@gi...> - 2004-11-17 00:21:15
|
Hi=20 John Peterson writes: > KIRK, BENJAMIN (JSC-EG) (NASA) writes: > > The EquationSystems class provides parameters, which are a mappin= g from an > > arbitrary string to a floating-point value... See example 2. Do = you think > > that would work? The GMVIO implementation can check for a releva= nt > > parameter and use it if it is present. Excellent, stupid me that I did not think of that!=20 > > I would be hesitant to add more to the MeshIO interface. My thou= ghts are > > that it should remain as simple as possible, essentially only pro= viding a > > read() and write() method. The reason for this is that the MeshI= O class 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.) OTOH: I think that one should be able to customize the I/O. So another 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: EquationSystems: parameters pertaining to the solution process MeshOutput: parameters pertaining to the output for a specific for= mat What are your thoughts about getting a fixed reference to a MeshInput or MeshOutput instance that is initialized on model setup. One could set the necessary paramters once, and the just call the write() method. This is in exact analogy to setting up an equation system, and then call the solve() method. > > If you need to extend the interface I'd do it to the GMVIO class.= The idea > > is that you only will call this extended interface when you *know= * you are > > dealing with GMV output, hence you will instantiate a GMVIO objec= t directly. > > This is opposed to the general case where you conceivably deal wi= th a MeshIO > > object and have no idea what implementation is actually being use= d. > >=20 > > Thoughts? >=20 >=20 > I would agree with Ben on that one. It seems our new mantra is "les= s is more" > as far as interfaces are concerned. BTW, I like the Idea of the Mes= hInput and I absolutely agree on the "less is more". [To read more nice mantras tr= y python -c "import this"] > MeshOutput classes, similar to the iostreams. In that design, who h= olds the > reference to the mesh? :) Why is there a need for a explicit reference to the mesh. Isn't this already provided by the EquationSystems? Like in EquationSystems es (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. Yes, indeed. There is a block "velocity" where the velocities can be specified (bottom of page 95 of the 3.3 user manual). These are then the standard vectors for GMV. Another nice way is to save the current state as attribute file ("Put attributes" under the file menu) and retrieve it later (with "Get attributes"). This preserves all settings (including vectors), and can also be used to create animations from batch jobs. Thanks for your thoughts! I'll submit a patch with "probtime" and "velocity" shortly. Best, Martin --=20 Martin L=FCthi University of Alaska, Fairbanks Dr. sc. nat. tel: +1 (907) 474 7691 fax: +1 (907) 474 7290 mel: lu...@gi... http://gi.alaska.edu/~luthi/ |
From: John P. <pet...@cf...> - 2004-11-17 02:33:49
|
Martin L=FCthi writes: > Hi=20 >=20 >=20 > Why is there a need for a explicit reference to the mesh. Isn't this= > already provided by the EquationSystems? Like in >=20 > EquationSystems es (mesh); I was referring to the MeshIO classes, which have a similar constructor= . Basically, we have a question of multiple inheritance: class MeshIO : public MeshInput, public MeshOutput {}; where in the current implementation both MeshInput and MeshOutput would= maintain references to the mesh. Ah, the difference would be that one is const while the other is not... That way MeshIO naturally gets its one const (for writing) and one non-const (for reading) Mesh reference,= not necessarily pointing to the same Mesh! duh. > > Can GMV do something special if you tell it that a certain variab= le is a > > velociyt? It'd be nice not to have to manually build the vector = in GMV every time. >=20 > Yes, indeed. There is a block "velocity" where the velocities can be= > specified (bottom of page 95 of the 3.3 user manual). These are then= > the standard vectors for GMV. Another nice way is to save the curren= t > state as attribute file ("Put attributes" under the file menu) and > retrieve it later (with "Get attributes"). This preserves all settin= gs > (including vectors), and can also be used to create animations from > batch jobs. Cool, I knew about the Get/Put Attributes and have used it before. The= only gripe I have about it is it is not smart enough to know when I hav= e loaded a different sized mesh with all the same variables. I guess it'= d be nice to not have to Get Attributes every time :) The vectors thing you are talking about would definitely be worth it, and would fit nicely in the GMVIO class as it stands. BTW, what can you do with "probtime"? I usually just write out a separate GMV file for each timestep. -John |
From: <lu...@gi...> - 2004-11-17 03:05:40
Attachments:
patch.gmv_io
|
Hi again A new version of gmv_io including the "velocity" and the "probtime" block is attached. However, there are several problems that I discuss in the context below. Martin L=FCthi writes: > John Peterson writes: > > KIRK, BENJAMIN (JSC-EG) (NASA) writes: > > > The EquationSystems class provides parameters, which are a map= ping from an > > > arbitrary string to a floating-point value... See example 2. = Do you think > > > that would work? The GMVIO implementation can check for a rel= evant > > > parameter and use it if it is present. >=20 > Excellent, stupid me that I did not think of that!=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. 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. > > > I would be hesitant to add more to the MeshIO interface. My t= houghts are > > > that it should remain as simple as possible, essentially only = providing a > > > read() and write() method. The reason for this is that the Me= shIO class is > > > kinda the bare minimum functionality we expect from *any* I/O > > > implementation... (Even as it stands it is a bit too much. W= hat is really > > > needed it MeshInput & MeshOutput which implement read() and wr= ite(), > > > respectively. MeshIO could simply inherit from both of these.= ) >=20 > 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 > EquationSystems: parameters pertaining to the solution process > MeshOutput: parameters pertaining to the output for a specific = format 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 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 ); As an alternative, one could pass a std::map<std::string, std::string>=20= to the write method GMVIO(equation_systems, parameters); > What are your thoughts about getting a fixed reference to a MeshInpu= t > or MeshOutput instance that is initialized on model setup. One could= > set the necessary paramters once, and the just call the write() > method. This is in exact analogy to setting up an equation system, a= nd > then call the solve() method. This has been made more explicit above. > > > If you need to extend the interface I'd do it to the GMVIO cla= ss. The idea > > > is that you only will call this extended interface when you *k= now* you are > > > dealing with GMV output, hence you will instantiate a GMVIO ob= ject directly. > > > 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? > >=20 > >=20 > > I would agree with Ben on that one. It seems our new mantra is "= less is more" > > as far as interfaces are concerned. BTW, I like the Idea of the = MeshInput and >=20 > I absolutely agree on the "less is more". [To read more nice mantras= try > python -c "import this"] 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 Cheers, Martin |
From: Benjamin S. K. <be...@cf...> - 2004-11-17 06:19:17
|
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 |
From: <lu...@gi...> - 2004-11-17 23:14:01
|
Benjamin S. Kirk writes: > Martin L=FCthi wrote: > >=20 > > Well, there are some problems with that. To specify the names of t= he > > velocity variables one would need strings, not numbers. At the mom= ent > > I set the velocity names to mandatory strings "U", "V", "W" which > > might interfere with others uses of these letters. >=20 > Probably what is needed is more explicit support for vectors at the=20= > System level. For example, one could declare >=20 > es("flow").add_scalar("rho"); > es("flow").add_vector("U"); > es("flow").add_scalar("T"); Yes, this sounds very good to me. But this should of course be=20 es("flow").add_scalar_variable("p", FIRST); es("flow").add_vector_variable("U", SECOND); > The main reason for this is because it better hides the dimensionali= ty=20 > of the problem from the user. Currently the user needs an if test o= n=20 > dimension to decide how many scalar components constitute a vector f= or=20 > their problem... This is just one problem. I don't know if dimension independence is so important (it is not for me). What is more important is that composite elements (vector elements) are easier to handle than now. Awkwared code blocks like this should be handled by the composite element, as it is quite easy to make errors, and it clutters the code. // reposition matrizes Kuu.reposition (u_var*n_u_dofs, u_var*n_u_dofs, n_u_dofs, n_u_d= ofs); Kuv.reposition (u_var*n_u_dofs, v_var*n_u_dofs, n_u_dofs, n_v_d= ofs); Kup.reposition (u_var*n_u_dofs, p_var*n_u_dofs, n_u_dofs, n_p_d= ofs); > > 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. AT= M > > this is only used to access the parameter "probtime" of the > > EquationSystem. >=20 > Yeah, by design... There are many cases where you won't even have a= n=20 > EquationSystems object and you want to use a MeshIO object to read/w= rite=20 > your mesh. After all, it's not EquationSystemsIO ;-), which begs th= e=20 > question: OK, this makes perfect sense. The above comment was more an explanation what I had to do to implement that functionality, not that I was happy with it. What is the rationale behind the implementation of write_equation_systems? void MeshOutput<MT>::write_equation_systems (const std::string& fname, =09=09=09=09=09 const EquationSystems& es) the building of variables, and the call of=20 this->write_nodal_data (fname, soln, names); =20 seems unnecessary to me. Shouldn't the writer class get the EquationSystems object, and implement everything? Then one could easily access the parameters. > Perhaps what is needed is one more level of abstraction? >=20 > template class IO<class T>; >=20 > class GMVIO<class T> : public IO<T> >=20 > Then a full specialization for GMVIO<Mesh> (essentially what we have= =20 > now) and GMVIO<EquationSystems> which could address more of these is= sues? >=20 >=20 > > > OTOH: I think that one should be able to customize the I/O. So = another > > > approach could be to add a std::map of parameters to the MeshIn= put / > > > MeshOutput class, in a similar way as in the EquationSystems cl= ass. > > > With such an approach the both concerns are kept seperated: > > >=20 >=20 > Note the templated approach allows you to use template specializatio= n=20 > to, uh, specialize the I/O. Well, I don't know whether that is necessary.=20 ---snip--- > 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: >=20 > class Parameters > { > template <typename T> > T operator () (const std::string&) const; > T & operator () (const std::string&) const; > }; >=20 >=20 > Parameters parameters; >=20 > parameters("foo") =3D 2; // integer > parameters("bar") =3D "baz"; // string Yes, this looks nicer.=20 > Then all that is needed is a few private maps and full specializatio= n of=20 > the member functions to implement a more general parameter handler c= lass. >=20 > The current parameters stuff in the EquationSystems class will get=20= > replaced by one of these, one could be added to the MeshIO class, th= e=20 > Partitioners certainly could use one, etc... This would definitively make things much easier. And separation of concerns is also met (no output parameters in EquationSystems). Best, Martin --=20 Martin L=FCthi University of Alaska, Fairbanks Dr. sc. nat. tel: +1 (907) 474 7691 fax: +1 (907) 474 7290 mel: lu...@gi... http://gi.alaska.edu/~luthi/ |