Re: Element Fields
They are essentially DOFs that live on elements. They can be many
things. Sometimes they are material properties... but sometimes they
are solutions themselves.
For instance, in our Mechanical simulations they solve for stress...
this is written as a tensor (usually symmetric) to an element field...
ie the stress is constant over the element.
Another example is chemistry... sometimes we solve for chemical
species... the concentrations of which are stored on a per element
basis.
As Roy mentioned a lot of these can be taken care of using the
monomials with p=0 (so they are constant over the element). A
trickier thing might be that most of these are vector/tensor valued.
Have we actually come to the point where we need vector valued
variables?
Everything that I'm going to be reading in is based on vector valued
variables... because that's how Sierra works. Now, that doesn't mean
that I can't handle a lot of this stuff in my userpsace app... just
creating multiple scalar valued variables like we always do... but it
might be nice to finally move to vector valued vars....
Derek
On Nov 14, 2007 9:17 AM, John Peterson <[EMAIL PROTECTED]> wrote:
> 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
