Hi Roy,

   Attached is a patch along the same lines of what I was saying. I have
tested it with the code examples, and also my application, and things seem
to be working OK.

   A few of comments about the patch:

-- The primary change is concerning the EquationSystems::read() which is
now a template function. I have had to make a few other changes in the read
methods to supprot that (equation_systems_io.C and system_io.C).

-- Consistency with this change required addition of template parameters to
the calles to these functions in reduced basis codes. This could easily be
avoided by adding default parameters to all templates, but I preferred to
add the default parameter to only the EquationSystem::read()

--  You will notice a few other changes:
--  I made a change to gmsh_io.C in the read method by adding the Mesh
verion 2.2 to the list of acceptable formats. I have using the code without
issues.

--  I have had to add a couple of utility functions to DenseMatrix, which
are included in the patch.

--  A few modifications to some methods in DenseMatrix and DenseVector
which are now templates for convenience in complex arithmetic.

--  Also, I am being persistent with the (potential bug
in) UnsteadySolver that I had sent an email about earlier this month. I
have included the proposed bug-fix in the patch, and hopefully you will
have a chance to test it out. I  have had to include this to ensure
consistency of my code.

Please test out the patch, and feel free to include/ignore any of these.

Thanks,
Manav



On Wed, Mar 20, 2013 at 6:35 PM, Roy Stogner <[email protected]>wrote:

>
> On Wed, 20 Mar 2013, Manav Bhatia wrote:
>
> Here is one potential solution:
>>
>> The ThreadedIO in system_io.C is the key.
>> If this is templatized using the value type, the appropriate
>> method XDR::data_stream() in  xdr_cxx.C will be called. So, providing the
>> template value (for ThreadedIO) to be Real when Number=Complex should do
>> the trick.
>>
>> The catch here is that this template value will have to be carried down
>> all
>> the way from EquationSystems::read().
>>
>> So, if Number = Complex, but the data in XDR is Real, then something
>> like EquationSystems::read<Real>() should work fine. In which case, all
>> methods down to System::read_serialized_block_**dof_object() will need an
>> extra template value.
>>
>> Does this sound reasonable?
>>
>
> We'd want a default template argument of Number for backwards API
> compatibility; otherwise this sounds excellent.  I'd be thrilled if
> the fix is this simple.
> ---
> Roy
>
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar
_______________________________________________
Libmesh-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/libmesh-users

Reply via email to