libMesh: A C++ Finite Element Library

That would be a very, very welcome patch. 

-Ben



On Oct 29, 2012, at 4:30 PM, "David Knezevic" <dknezevic@...> wrote:

> I'd like to be able to plot data from a subset of the Systems in an 
> EquationSystems object. I generally use write_equation_systems, which 
> writes out data from all the systems. I didn't notice functionality for 
> specifying a subset of the systems, but I wanted to check?
> 
> Otherwise, I guess a patch would involve some edits to MeshOutput and 
> EquationSystems so that I can pass in a std::set<std::string>* (that 
> defaults to NULL) of system names? If this sounds like desirable 
> functionality more generally, I'll be happy to make a patch.
> 
> Thanks,
> David
> 
> 
> ------------------------------------------------------------------------------
> The Windows 8 Center - In partnership with Sourceforge
> Your idea - your app - 30 days.
> Get started!
> http://windows8center.sourceforge.net/
> what-html-developers-need-to-know-about-coding-windows-8-metro-style-apps/
> _______________________________________________
> Libmesh-users mailing list
> Libmesh-users@...
> https://lists.sourceforge.net/lists/listinfo/libmesh-users

The attached patch does the job for me. Let me know if there are any 
suggestions, otherwise I'll go ahead and check it in.

David




On 10/29/2012 07:18 PM, Kirk, Benjamin (JSC-EG311) wrote:
> That would be a very, very welcome patch.
>
> -Ben
>
>
>
> On Oct 29, 2012, at 4:30 PM, "David Knezevic" <dknezevic@...> wrote:
>
>> I'd like to be able to plot data from a subset of the Systems in an
>> EquationSystems object. I generally use write_equation_systems, which
>> writes out data from all the systems. I didn't notice functionality for
>> specifying a subset of the systems, but I wanted to check?
>>
>> Otherwise, I guess a patch would involve some edits to MeshOutput and
>> EquationSystems so that I can pass in a std::set<std::string>* (that
>> defaults to NULL) of system names? If this sounds like desirable
>> functionality more generally, I'll be happy to make a patch.
>>
>> Thanks,
>> David
>>
>>
>> ------------------------------------------------------------------------------
>> The Windows 8 Center - In partnership with Sourceforge
>> Your idea - your app - 30 days.
>> Get started!
>> http://windows8center.sourceforge.net/
>> what-html-developers-need-to-know-about-coding-windows-8-metro-style-apps/
>> _______________________________________________
>> Libmesh-users mailing list
>> Libmesh-users@...
>> https://lists.sourceforge.net/lists/listinfo/libmesh-users

On Mon, 29 Oct 2012, David Knezevic wrote:

> The attached patch does the job for me. Let me know if there are any 
> suggestions, otherwise I'll go ahead and check it in.

Looks good.  While we're at it should we just go whole hog and
figure out how to supply a list of sysname/varname pairs if desired
too?  That FEType parameter is kind of a poor hack.
---
Roy

On Mon, Oct 29, 2012 at 10:09 PM, Roy Stogner <roystgnr@...:

> While we're at it should we just go whole hog and
> figure out how to supply a list of sysname/varname pairs if desired
> too?  That FEType parameter is kind of a poor hack.


That'll be a bit more work, I think, because Exodus output, for example,
relies on that API for outputting element data (i.e. CONSTANT MONOMIAL
variables). I have no problem with the change, but thought I'd forewarn
before someone starts down that road.

Best,

Paul

On 10/29/2012 11:13 PM, Paul T. Bauman wrote:
> On Mon, Oct 29, 2012 at 10:09 PM, Roy Stogner 
> <roystgnr@... <mailto:roystgnr@...>> wrote:
>
>     While we're at it should we just go whole hog and
>     figure out how to supply a list of sysname/varname pairs if desired
>     too?  That FEType parameter is kind of a poor hack.
>
>
> That'll be a bit more work, I think, because Exodus output, for 
> example, relies on that API for outputting element data (i.e. CONSTANT 
> MONOMIAL variables). I have no problem with the change, but thought 
> I'd forewarn before someone starts down that road.

I agree that the FEType parameter is a bit hackish. It'd be good to be 
able to specify sys/varname pairs.

I haven't looked into the Exodus issue that Paul's referring to, though.

On Mon, Oct 29, 2012 at 9:09 PM, Roy Stogner <roystgnr@...:

> Looks good.  While we're at it should we just go whole hog and
> figure out how to supply a list of sysname/varname pairs if desired
> too?  That FEType parameter is kind of a poor hack.
>

It should be noted that you can already restrict what variables come out
into an Exodus file.  On your ExodusII_IO object just use
set_output_variables()

Derek

On Tue, 30 Oct 2012, Derek Gaston wrote:

> It should be noted that you can already restrict what variables come
> out into an Exodus file.  On your ExodusII_IO object just use
> set_output_variables()

Interesting; I hadn't noticed that method when it went in.  Looks like
you're out of luck if a single EquationSystems has more than one
System with the same variable name, but then I suspect pretty much all
our I/O other than xda/xdr fails in one way or another in that case.

Any complaints about that method's semantics?  If not, then when we
ever get around to implementing that capability in other output
formats it seems like the thing to do would be simply to move that
method up from ExodusII_IO to MeshOutput and then examine the result
in the other subclasses.
---
Roy

On Tue, Oct 30, 2012 at 10:07 AM, Roy Stogner <roystgnr@...:

> Interesting; I hadn't noticed that method when it went in.  Looks like
> you're out of luck if a single EquationSystems has more than one
> System with the same variable name, but then I suspect pretty much all
> our I/O other than xda/xdr fails in one way or another in that case.
>

Yeah - I've always assumed that that use case is just not supported.  Our
software simply doesn't allow it at all.


> Any complaints about that method's semantics?  If not, then when we
> ever get around to implementing that capability in other output
> formats it seems like the thing to do would be simply to move that
> method up from ExodusII_IO to MeshOutput and then examine the result
> in the other subclasses.


This would be really great.  For one thing... what I did in the Exodus
writer is sub-par because we still do all the parallel communication and
projection (if needed) for that variable... and then it just gets filtered
out at the Exodus writing stage.  That's still nice (because we have
simulations with thousands of variables... but typically only need to write
out a few) but it would be great to get rid of the extra overhead.

Oh - while we're on this subject.... I'll bring up again that
EquationSystems::build_solution_vector() is doing several full
serializations (all-to-all full copies) of the global solution vector.
 This is happening in System::update_global_solution() ....

When we're running rather large problems (100M DoFs+ on 10k+ processors)
this actually can be a significant issue: a full copy of the solution
vector for 100M+ DoFs is ~1GB... which, when you have 32 MPI processes on
the same box can cause quite a big issue!  Not too mention the time
necessary to do a full localization to every processor.

When we're using a parallel IO format (like Nemesis) we REALLY need to NOT
do this full localization.  The problem is that this is down in
EquationSystems and System (and quite complicated).  I've tried to fix it
before... but haven't really come up with great solution....

Derek

OK, so for now should I go ahead and check in my patch from yesterday?


> On Tue, Oct 30, 2012 at 10:07 AM, Roy Stogner <roystgnr@...:
>
>> Interesting; I hadn't noticed that method when it went in.  Looks like
>> you're out of luck if a single EquationSystems has more than one
>> System with the same variable name, but then I suspect pretty much all
>> our I/O other than xda/xdr fails in one way or another in that case.
>>
> Yeah - I've always assumed that that use case is just not supported.  Our
> software simply doesn't allow it at all.

Actually, it does work for GMV, and I think it also works for exodus in 
paraview. When you visualize the results you just have multiple 
variables with the same name, so it gets confusing as to which variable 
came from which system... so I think it would nice to be able to specify 
system/variable pairs, though I agree it's not a high priority.

David

On Oct 30, 2012, at 12:34 PM, David Knezevic <dknezevic@...> wrote:

> OK, so for now should I go ahead and check in my patch from yesterday?
> 

I'm OK with it.