Seems like something got broke
 

Seems like something got broken during the modifications that were necessary due to version changes of OF. I will have a look at it when I find the time

Bernhard

Hi Bernhard, Thank you for
 

Hi Bernhard,

Thank you for your attention. I figured out that during a "continuation run", the constructor below is called (which is different from the one called during the initial run), by the constructor of "IncompressibleCloud", which in turn take advantage of the constructor of template "Cloud". However, the parameter "readFields" below is set to be "false" by default by Cloud<particletype>::Cloud. Therefore, in the constructor of SoftParticle (below), the statements after "if (readFields)" are not executed. And thus the diameter "d" has no initialized values (actually with unpredictable values). Some of them are with very big number as 1.5E+312 (I used a 64-bit machine). Consequently, when "calculateDerived" is called, in the following statment:

m = 4/3 * density * d*d*d/8

m becomes too large causing floating exception.

However, when I forcibly set readFields to "true" to make the following statement executed,

Info << "Reading ASCII format: " << endl;
d_ = readScalar(is);
mass_ = readScalar(is);
is >> U_;

the field reading statement are not reading correctly. Not sure why, they are trying to read file "position" instead of "d", or "U". I don't know how to set it correctly.

However, (yet another), I commented out the call of "calculateDerived" in this function, i.e. the function as a whole is commented out essentially (because the statement after "if(readFields)" is not executed, and then the whole code works correctly!!! I found that you have a function:

void Cloud<hardballparticle>::readFields()

in the file "IncompressibleCloudIO.C. This function reads in "d", "m", and "U" correctly. So the problem is actually solved, but I don't know where the function "readFields" is called in the process, and why you call "calculatedDerived" in the constructor and then read in "d", "m", "U" again.

Anyway, it was a long story above, here is a summary below:
1. The problem was caused by the failure of reading "d" in the constructor of "HardBallParticle" (see below), and the call of function "calculateDerived" after the incorrect (absent) reading.
2. I commented out that function call, and the continuation run works now.
3. The function void Cloud<hardballparticle>::readFields() did the job of reading "d" and "U" correctly. But I don't know where it is called and how the whole thing works.

If you could give any hints, I would greatly appreciate that.

Best,
Heng


The constructor of HardBallParticle:
---------------------------------
HardBallParticle::HardBallParticle
(
const Cloud<softparticle>& cloud,
Istream& is,
bool readFields
)
:
particle<hardballparticle>(cloud, is)
{
if (readFields)
{
if (is.format() == IOstream::ASCII)
{
Info << "Reading ASCII format: " << endl;
d_ = readScalar(is);
mass_ = readScalar(is);
is >> U_;
}
else
{
is.read(reinterpret_cast<char*>(&d_),sizeof(d_));
is.read(reinterpret_cast<char*>(&mass_),sizeof(mas s_));
is.read(reinterpret_cast<char*>(&U_),sizeof(U_));
}
}

// d, m, U are not read correctly in this function, so
// calculateDerived would cause trouble here. It is disabled for
// now. This function is thus dummy. XH

// calculateDerived();

is.check("HardBallParticle::HardBallParticle(IStre am &");
}

Hi Heng! Thanks for the det
 

Hi Heng!

Thanks for the detailed description. I moved the calculateDerived into the if (where it belonged in the first place).

Please note that icoLagrangianFoam is practically a 1.3-code that happens to compile on 1.4.x. With the new lagrangian-classes there are more elegant ways to treat patches (never had the time to change that part)

Bernhard