Looks like the attachment was stripped, the lines added to ex11.C at the
end of the main function were:
bool generate_xdr_data = false;
if(generate_xdr_data)
{
Xdr header_data_out("header.xdr", ENCODE);
equation_systems.get_system("Stokes").write_header(header_data_out,
"", false);
Xdr solution_data_out("solution.xdr", ENCODE);
equation_systems.get_system("Stokes").write_serialized_data(solution_data_out,
false);
}
else
{
Xdr header_data_in("header.xdr", DECODE);
equation_systems.get_system("Stokes").read_header(header_data_in,
"", false);
Xdr solution_data_in("solution.xdr", DECODE);
equation_systems.get_system("Stokes").read_serialized_data(solution_data_in,
false);
}
On 09/26/2011 11:51 PM, David Knezevic wrote:
> I sent the message below earlier to libmesh-devel, but my message was
> pretty vague (apologies for that)... I wanted to follow up with a
> concrete test case to see if anyone could help out.
>
> I've attached a slightly modified version of ex11.C: run it once with
> "generate_xdr_data=true" to generate data, then again with
> "generate_xdr_data=false" to read the data in. When I set
> "generate_xdr_data=false", I get the error reported below. (This only
> happens with >1 variables in the system.) Any thoughts on what I
> should change would be appreciated.
>
> Many thanks,
> David
>
>
>
>
> On 09/15/2011 04:44 PM, David Knezevic wrote:
>> Hi all,
>>
>> RBEvaluation makes a direct call to write_header and read_header, and
>> this seems to be causing a problem.
>>
>> For example, when I modify ex23 so that it has two variables ("u" and
>> "v") rather than one, I get an error in rb_evaluation.C:1029 when the
>> system tries to read in a header file before reading the subsequent
>> sequence of .xdr files. The stack trace is below; the system is
>> looking for a variable with name "", whereas it should be "u".
>>
>> The header is written in rb_evaluation.C:
>>
>> Xdr header_data(file_name.str(), ENCODE);
>> sys.write_header(header_data, "", false);
>>
>>
>> and also read in rb_evaluation.C with:
>>
>> Xdr header_data(file_name.str(), DECODE);
>> sys.read_header(header_data, "", false);
>>
>> I was wondering if there's anything obviously wrong with this usage
>> of read/write_header? These methods appear to be used in a similar
>> manner in equation_systems.C. In particular, I can't see why the
>> 2-variable case triggers an error whereas the 1-variable case works
>> fine?
>>
>> Many thanks,
>> Dave
>>
>>
>> -----------------------------------------------------------------------------------------------------------------
>>
>>
>>
>> ERROR: variable does not exist in this system!
>> [0] src/systems/system.C, line 1076, compiled Sep 6 2011 at 22:15:39
>> terminate called after throwing an instance of 'libMesh::LogicError'
>> what(): Error in libMesh internal logic
>>
>> Program received signal SIGABRT, Aborted.
>> 0x00007ffff08ccd05 in raise (sig=6) at
>> ../nptl/sysdeps/unix/sysv/linux/raise.c:64
>> 64 ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or
>> directory.
>> in ../nptl/sysdeps/unix/sysv/linux/raise.c
>> (gdb) bt
>> #0 0x00007ffff08ccd05 in raise (sig=6) at
>> ../nptl/sysdeps/unix/sysv/linux/raise.c:64
>> #1 0x00007ffff08d0ab6 in abort () at abort.c:92
>> #2 0x00007ffff0ce86dd in __gnu_cxx::__verbose_terminate_handler() ()
>> from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
>> #3 0x00007ffff6e670ef in libMesh::libmesh_terminate_handler () at
>> src/base/libmesh.C:200
>> #4 0x00007ffff0ce6926 in ?? () from
>> /usr/lib/x86_64-linux-gnu/libstdc++.so.6
>> #5 0x00007ffff0ce6953 in std::terminate() () from
>> /usr/lib/x86_64-linux-gnu/libstdc++.so.6
>> #6 0x00007ffff0ce6a5e in __cxa_throw () from
>> /usr/lib/x86_64-linux-gnu/libstdc++.so.6
>> #7 0x00007ffff76bf96f in libMesh::System::variable_number
>> (this=0x7ea930, var=...) at src/systems/system.C:1076
>> #8 0x00007ffff76d2d4f in libMesh::System::read_header
>> (this=0x7ea930, io=..., version=..., read_header=false,
>> read_additional_data=true, read_legacy_format=false) at
>> src/systems/system_io.C:232
>> #9 0x00007ffff7675450 in
>> libMesh::RBEvaluation::read_in_basis_functions (this=0x7fffffffd920,
>> sys=...,
>> directory_name=..., read_binary_basis_functions=true) at
>> src/systems/rb_evaluation.C:1029
>> #10 0x000000000044c09f in main (argc=1, argv=0x7fffffffe668) at
>> ex23_vector.C:144
>
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and makes
> sense of it. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2dcopy1
>
>
> _______________________________________________
> Libmesh-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/libmesh-users
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
_______________________________________________
Libmesh-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/libmesh-users
