On Jan 11, 2012, at 12:52 PM, Roy Stogner wrote:

> 
> Please hit "reply to all" to make sure questions go to libmesh-users;
> if I didn't know that this stuff was getting archived to let Google
> help additional users later, I doubt I'd find the time to answer as
> many questions in the first place.

My bad, I wasn't aware that this excludes libMesh user list.

> On Wed, 11 Jan 2012, Ataollah Mesgarnejad wrote:
> 
>> Correct me if I'm wrong please, but it seems that this doesn't have any 
>> support for the vectors and matrices that you add to
>> your systems and are not part of the solution variables? 
> 
> We do automatically write out user-added vectors (at least in
> xda/xdr files; not sure about other formats), but not user-added
> matrices.  Or any other matrices, for that matter; I guess we've
> always thought of those as dependent data that could be recalculated
> from the independent vectors in a restart file.
> 
> A patch to save just matrix metadata (probably just the name) to
> automatically re-add-matrices upon restart wouldn't be a bad idea, but
> it would be mildly tricky to implement, since ImplicitSystem would
> have to override some of the system_io code.

If you can point me to where you did this for vectors I can try to add the 
needed code so we don't won't have a problem with added matrices.
> 
 
> I wouldn't mind a patch adding the option to save matrix contents,
> even, but it would have to be an option, off by default; otherwise
> it'd be too much unused bloat in most people's restart files.
>> This isn't a major set back for me but I want to be able to add such vectors 
>> and matrices nevertheless when I restart the
>> calculation; if I try to do this after reading the equation system I get the 
>> following:
>>  ERROR: Too late.  Cannot add matrices to the system after initialization 
>> any more.  You should have done this earlier.
> 
> Yes, the initial libMesh design only allowed the addition of new
> vectors or matrices before System::init().  I went in and fixed that
> for vectors, but someone would have to go back in and do the same for
> the matrices.  I don't have time to do so myself but I'd love a patch.
> I think it'd be easy to efficiently handle late matrix addition in
> most cases, the only exception would be the perverse case where prior
> matrices didn't need a full sparsity pattern (so the DofMap didn't
> bother calculating it) but the new matrix does.
> 
>> and if I do it before reading the system they would be removed and I get 
>> something like this:
>>  ERROR: matrix Hessian does not exist in this system!
>> Is this a bug or do I need to set a variable somewhere so this doesn't 
>> happen?
> 
> Set a variable.  The default EquationSystems::read() flags include
> READ_HEADER, which is superfluous if you've already done all the
> add_variable, add_vector, etc. setup that the header would otherwise
> have been required to specify, and which is actively damaging if your
> System subclass's clear() method removes data (like matrix existence)
> which the header doesn't know how to re-add.

The reason I asked this was I thought if the  EquationSystems::read() doesn't 
go and init the EquationSystem I don't see a reason why you won't be able to 
add a Matrix after EquationSystems::read()?

> ---
> Roy

Thanks,
Ata
------------------------------------------------------------------------------
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual 
desktops for less than the cost of PCs and save 60% on VDI infrastructure 
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
_______________________________________________
Libmesh-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/libmesh-users

Reply via email to