Sorry, in my previous post I was not too specific. I need to write out a
complex valued vector. I write out my data using MeshData::write(**),
which in my case calls MeshData::write_xdr(**), which calls Xdr::data(**).
By doing so in the former libmesh version, the vector entries were
written out by this loop:
for (unsigned int i=0; i<v.size(); i++)
{
libmesh_assert (out.get() != NULL); libmesh_assert (out->good());
OFSNumberscientific(*out,17,v[i]) << " ";
}
Hence, two consecutive complex valued entries were written out like this:
1.00000000000000000e+00 2.00000000000000000e+00 3.00000000000000000e+00
4.00000000000000000e+00
Now, the call of MeshData::write(**) leads to the following loop
(xdr_cxx.C line 522):
for (unsigned int i=0; i<a.size(); i++)
{
libmesh_assert (out.get() != NULL); libmesh_assert (out->good());
this->do_write(a[i]);
}
with
do_write(std::complex<T>& a) { *out << a.real() << "\t " << a.imag(); }
The same two consectutive entries as above are now written out like this:
1 23 4
(no space between 2 and 3, no scientific notation)
But you're right, the Xdr::data_stream(**) function avoids this problem,
however, by calling MeshData::write(**) I don't reach
Xdr::data_stream(**) but only Xdr::data(**). In example ex10, the data
is written out over EquationSystems::write(**), which in the end leads
to System::write_SCALAR_dofs(**) which calls Xdr::data_stream(**) and
everything is fine.
As far as I can tell, adding << " "; after a.imag() should do the trick.
Or am I missing something? Sorry to bother you!
best reagrds
Loris
On 03/23/2011 04:14 PM, Roy Stogner wrote:
>
> On Wed, 23 Mar 2011, Loris Nagler wrote:
>
>> I recently updated libmesh to version 0.7.0.4. In a former version,
>> the function
>>
>> void Xdr::data (std::complex<double>& a, const char* comment)
>>
>> which is defined in xdr_cxx.C, wrote out complex numbers like this:
>>
>> *out << a.real() << "\t " << a.imag() << "\t " << comment << '\n';
>>
>> whereas now they are written out like this (now using
>> do_write(std::complex<T>& a) ):
>>
>> *out << a.real() << "\t " << a.imag();
>
> Take a look at Xdr::data again in the new version - it calls
> do_write() to do the above, but then adds the final
> tab/comment/newline itself.
>
> For Xdr::data(vector<*>), on the other hand... it does look like we're
> missing separators between data points... but we manage to avoid
> triggering it because all the library code uses the older
> Xdr::data_stream method instead.
>
>> Due to a missing space or tab after a.imag(), the imaginary part of
>> one entry is directly attached to the real part of the next entry.
>> No wonder my input files are pretty messed up since the update ;) .
>
> Could you give us an example, or better yet a test case that generates
> an example? I tried to replicate the problem with ex10 using
> --enable-complex, but saved_solution.xda from that run looks just
> fine.
> ---
> Roy
>
>
> ------------------------------------------------------------------------------
> Enable your software for Intel(R) Active Management Technology to meet the
> growing manageability and security demands of your customers. Businesses
> are taking advantage of Intel(R) vPro (TM) technology - will your software
> be a part of the solution? Download the Intel(R) Manageability Checker
> today! http://p.sf.net/sfu/intel-dev2devmar
>
>
> _______________________________________________
> Libmesh-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/libmesh-users
>
------------------------------------------------------------------------------
Enable your software for Intel(R) Active Management Technology to meet the
growing manageability and security demands of your customers. Businesses
are taking advantage of Intel(R) vPro (TM) technology - will your software
be a part of the solution? Download the Intel(R) Manageability Checker
today! http://p.sf.net/sfu/intel-dev2devmar
_______________________________________________
Libmesh-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/libmesh-users
