[ngj]

Dear all,

I have a small problem with IO of Field<Type> to and from dictionaries. I have, say, a vectorField named k of size 50 and a dictionary named dict.

I add the field k to dict in a preprocessing program by

dict.add("waveNumber", k, true);

In the dictionary, I get the following:

waveNumber 50 ( (<vector0>) ... (<vector49>) );

However, because it does not look like

waveNumber nonuniform List<vector> 50 ( (<vector0>) ... (<vector49>) );

I cannot read the field into another program in the constructor with the command

k_("waveNumber", dict, 50 )

Adding "nonuniform List<vector>" by hand solves the problem.

My question is, how I can write the field in the correct way from the very start?

Thanks a lot for your help,

Niels

[marupio]

I'm on the windows side doing post-processing this morning, so I can't look through the code in too much depth. But I can tell you, there is only one function that writes "nonuniform" to the Ostream, and that's Field::writeEntry. I guess using dictionary.add doesn't lead to this function.

Maybe that will help you a little...

[ngj]

Hi David

Thanks for your answer. I followed that lead as well, as I had seen e.g. boundary conditions writing with nonuniform, but I found myself in a dead end.

I also tried doing a brute force:

dict.add("waveNumber nonuniform List<vector>", k, 50);

but the compiler literally yelled at me, when I gave it to her - and all of the spaces are removed from the string anyway.

/ Niels

[marupio]

This problem was too tempting... so I switched to Linux...

When you use dictionary::add, it first converts your Field into a primitive entry, which writes it directly with operator<< instead of writeEntry, thus bypassing the "nonuniform" stuff.

I think the simplest way to get it to use writeEntry may be to make it into a "DimensionedField". Can you do that? DimensionedField uses writeEntry. You'd need a mesh and a dimensionSet. Your output would have the dimensionSet added as another keyword "dimensions".

The next easiest would be to create a custom derived "writeableField<Type>", which inherits Field, and does everything Field does, except override operator<< to use writeEntry.

-Dave

[ngj]

Thanks!

I will try either of your suggestions tomorrow morning.

/ Niels

[ngj]

Hi

Just to give a small update. I was not quite successful, however, I have made a ad-hoc solution, which only needs a tiny amount of manual interference. Instead of using

add("amp", amplitude, true)

where amplitude is a scalarField, I constructed a string as follows:

std::stringstream samp;

samp << "nonuniform List<scalar> " << amplitude.size() << "(";
forAll(amplitude, index)
{
    samp << amplitude[index] << " ";
}
samp << ")";

and then the write command looks like this:

dict_.add("amplitude", samp.str(), true);

It does, unfortunately leave " around the string in the dictionary, but it is easy to handle those in a small bash-script.

The solution is not as elegant as the one David suggested, however, it is a solution, which will definitely crash, if one forgets to use the bash-script, whereas the method first reported continues with a faulty field!

All the best,

Niels

[ngj]

And to put a final closure to the issue:

I added the following piece of code into the pre-processing program

std::string cmd("sed -e 's/\"nonuniform/nonuniform/' -e 's/)\";/);/' constant/waveProperties > constant/waveProperties.irregular; mv constant/waveProperties.irregular constant/waveProperties");

std::system( cmd.c_str() );

It works, so I am happy

Kind regards,

Niels

[ngj]

A small update on the above problem:

The method outlined above only works for short strings! In OF there is a hard-coded limit for the concatenation of strings, where the string is not allowed to exceed 1024 characters. This restriction seems weird as OF hardly uses strings, so why have such a limit?

Kind regards,

Niels