Two ways of saving ascii data, NOT the SAME?

Palabos General
#1

The saveAsciiData function I found in the post “postprocessing 3D fields in matlab” is really a convient way to save data in ascii code. However, I found the output data file is different from the way I used before.
Before I use the saveAsciiData, the following method is taken to save Pressure and velocity, and the data can be analysed in Tecplot:
(A)
//=============================================================================================
if (iter%converter.nStep(fSave)==0 && iter>0) {
ofstream myfile;
myfile.open (“outputPressure.dat” ) ;

    cout   <<  "Outputing data...";
    myfile <<  "variables=\"X\",\"Y\",\"P\" " << endl;
    myfile <<  "ZONE, I=" << GridNx << "," << " J=" << GridNy << endl;
      for (int ly=0; ly<GridNy; ++ly) {
        for (int lx=0; lx<GridNx; ++lx) {
            double pressure;
            pressure = lattice.getDataAnalysis().getPressure().get(lx,ly);
			                    
            myfile << setw(5) << (double)(lx+1) <<
                      setw(5) << (double)(ly+1)  <<
                      setw(15) << pressure << endl;

        }
   }
 myfile.close();
    cout << "Done." << endl;
 }

//=============================================================================================
However, after I use the saveAsciiData to save ascii data, take pressure for example, the following “pressure.dat” seems not the same with the file “outputPressure.dat” obtained above.
(B )
if (iT%converter.nStep(imSave)==0 && iT>0) {
cout << “Saving Pressure.dat…”;
saveAsciiData(lattice.getDataAnalysis().getPressure(), “pressure.dat” ) ;
cout << “Done.” << endl;
}

Dear all, could you tell why the two files obtained by
(A)pressure = lattice.getDataAnalysis().getPressure().get(lx,ly);
and
(B )saveAsciiData(lattice.getDataAnalysis().getPressure(), “pressure.dat” ) ;
are different?

PS: And if I use saveAsciiData(lattice, “lattice.dat” ) ; , what kind of structure is the “lattice.dat”, how should I understand the content in the file?

PS: the content of function saveAsciiData:
//=============================================================================================
template
void saveAsciiData(Serializable const& object, std::string fName) {
std :: ofstream* ostr = 0;
if (singleton::mpi().isMainProcessor()) {
ostr = new std :: ofstream(fName.c_str());
OLB_PRECONDITION( ostr );
}
DataSerializer const& serializer = object.getSerializer(IndexOrdering::memorySaving);
while (!serializer.isEmpty()) {
int bufferSize;
const T dataBuffer = serializer.getNextDataBuffer(bufferSize);
if (singleton::mpi().isMainProcessor()) {
for (int iData=0; iData<bufferSize; ++iData) {
*ostr << dataBuffer[iData] << endl;
}
}
}
delete ostr;
}
//=============================================================================================

#2

It seems to me that with method ( A ), each data row consists of three entries as follows,

xCoord yCoord Pressure
xCoord yCoord Pressure
xCoord yCoord Pressure
…

whereas with method ( B ), the coordinates are not stored, and each row only contains one value:

Pressure
Pressure
Pressure
…

Lacking the coordinates could be an issue with an irregular grid. In the present case however, the grid is regular (a matrix), and you can reconstruct the coordinates during data processing. In Octave or in Matlab, you would do something like

load pressure.dat
pressure = reshape(pressure, 200,300); % In case the size of the matrix is 200x300

I don’t know Tecplot, but would be very surprised if it hadn’t the ability to reconstruct the coordinates of a regular grid.

#3

Thank you Jonas! I haven’t get the outdata reshaped:-(
And there is still one thing confussing me – If I use saveAsciiData(lattice, “lattice.dat” ) , how the data is organised in the “lattice.dat”, which contains lots of data? The function saveAsciiData you offered seems to be a very convenient way to save ascii data :slight_smile:

#4

Oh, good point. You are right: the data is actually not structured the same way in (A) as in (B ). In (A), the outer loop is on y, and the inner loop on x, whereas in (B ) the outer loop is on x, and the inner loop on y. Note that the data structure of (B ) is closer to the data layout used by OpenLB. In OpenLB, memory is contiguous on the last index (y in 2D, and z in 3D).

If you want to use method (B ) but get the same ordering as in (A), you should reorder the indexes. This is easy to achieve: replace “IndexOrdering::memorySaving” by “IndexOrdering::backward”.