Derek Gaston writes:
> Do we need to do some redesign of equation_systems_io ? Right now it
> appears that you can only read xdr/a files for reading equation
> systems.... is this true?
Yep.
> I see that GMV now has a "copy_nodal_solution" to allow you to copy in
> a solution from a GMV file... but it appears that the equation system
> itself has to be all setup before that happens (ie the variables
> defined and such).
Right, this is a hack. I wanted to be able to read in a solution from
a GMV file, but the GMVIO class knows nothing about EquationSystems
(and it shouldn't need to, since it was originally designed as a MeshIO
object).
Since we will probably want to read solutions from other types
of files in the future, it seems that a family of EquationSystemsIO
classes would be a more appropriate design. They would leverage the
existing MeshInput/Output classes: for example, a GMVEquationSystemsIO
class might contain a (mesh-reading) GMVIO object. I believe
Wout Ruijter is looking at doing the same type of thing for VTK files.
Problems arise due to the information which is and is not available in
different types of file formats. For example, GMV has no notion of
"Systems", just "variables", so you have to bring in external knowledge
about which variable goes where in your EquationSystems. Other issues
include e.g. quadratic element support (most viz tools don't support these well)
as well as the file format-dependent ordering of solutions.
> I would really like to be able to do an es.read("something.e") and
> just have it work... do you guys think that's feasible?
I think pretty much anything's possible in this area given enough
coding time. The problems aren't conceptual (like: how do you parallelize
the mesh) but practical in nature.
> For now I'm just going to go down the path GMV went... just to get
> something running.
>
> Also... Exodus files have "Element Fields" in them... essentially
> scalar (and vector actually) values that are defined on elements
> (sometimes only a subset of elements). Do you guys have any ideas on
> how we would support that?
Are you talking about material properties? I'd have to know more about
it to say if it could be generalized to something else we already have in
the library. I'd start off by extending your current Exodus reader to
read in Element Fields as well.
-John
> Thanks!
> Derek
>
> On Nov 13, 2007 5:31 PM, Roy Stogner <[EMAIL PROTECTED]> wrote:
> > On Tue, 13 Nov 2007, Derek Gaston wrote:
> >
> > > Just a heads up that I'm doing some work to allow you to import a
> > > (nodal for now) solution from an Exodus file and also write solutions
> > > to an Exodus file. Over the next couple of days I'll probably be
> > > checking in partial capability as I go.... so if you see some churning
> > > down in that area... that's what's up.
> >
> > Hey, I left adaptive coarsening in a potentially broken state for a
> > week without realizing it; I think the SVN head is going to be in a
> > state of churn for a little while whether you're helping screw it up
> > or not. ;-)
> >
> > Just shout first if you find yourself wanting to make major changes
> > outside Exodus-specific code.
> >
> > > I might also be pinging some of you for help if I get stuck...
> >
> > I'm not on IM tonight and pretty busy this week, but I'll try to get
> > back to you on libmesh-devel without too much turnaround time.
> > ---
> > Roy
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Libmesh-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/libmesh-devel
