[gschaider]

To be honest I'm still working with the downloaded binary distribution (I've avoided recompiling the official distribution, because other people are using that installation too).

I'll install me a separate copy and give it a try.

(On the other hand by using the official binaries I am pretty sure that it's not my/my compilers fault. BTW: Could anyone reproduce this problem or is it something that only happens with my installation? - Can't imagine how, but ...)

[adorean]

It's happening to me too. In the /lagrangian subdirectory, the output is only "points".
I haven't got the time to take an in depth look to the problem though.

Ervin

[adorean]

My mistake. The output in the /lagrangian subdirectory is "positions".

Another thing. Is there a problem in restarting a dieselFoam case? It gives a message of out of range temperature, T=1e+163 or something similar.

Thanks.

[niklas]

I think I've found the mistake.

Have a look into src/lagrangian/basic/Cloud/CloudIO.C

and comment the readFields() and writeFields() routines.

N

[niklas]

maybe this wasnt such a brilliant idea after all, it will break other things....

N

[hjasak]

Nope, not a good idea... but I'd still like a bug fix. :-) Could you please post it when you figure it out.

Thanks,

Hrv

[niklas]

ok, this works...

as above remove the stuff from CloudIO.C
and add the lines below to src/lagrangian/basic/passievParticle/passiveParticleCloud.C

template<>
void Cloud<passiveparticle>::readFields()
{}

template<>
void Cloud<passiveparticle>::writeFields() const
{}

and the corresponding to indexedParticleCloud.C

is this acceptable?

N

[niklas]

> is this acceptable?
nope...

Just declare readFields() and writeFields() as virtual in Cloud.H, i.e.
//- Write the field data for the cloud of particles
virtual void writeFields() const;

Thanks Henry for the solution.

[gschaider]

My guess (but it's a long time since I've worked with template specialisation):

Usually the Define NoRepository is set (for most architectures)

Because of this in Cloud.H includes Cloud.C and that includes CloudIO.C with the most general template.

Any source-code including Cloud.H (because he needs a declaration of Cloud to define his template spezialisation) finds the general case before the specialized template.

I think some compilers prefer the general case to the specialized in such situations (although Lord Stroustrup says that it doesn't matter). Could it be that gcc 4.0.1 (which I believe was distributed first with 1.2) has fallen back to this bad behaviour?

[gschaider]

Sorry for my garbage. I didn't read Niklas last posting.

[gschaider]

Maybe it's not the right topic, but it fits to the course of this discussion:
As the dieselFoam-Solver is much too sophisticated for our purposes here I wrote a little demo-solver that only does some basic particle tracking (no evaporation etc).

It can be found at

http://openfoamwiki.net/index.php/Contrib_icoLagr angianFoam

It only serves as a demonstation and doesn't resemble the real world.

[mattijs]

nice! So what are you using it (lagrangian tracking) for?

[gschaider]

Myself I'm not using it. I did it as a feasability study for a colleague who plans to use it for a project for particle sprays and another with particle interception in a production process.

[stefanke]

Hi,

I try to fix the bug in lagrangian lib according to this posting:

declare writeFields() and readFields() as virtual in src/lagrangian/basic/Cloud.H

Then I recompiled the liblagrangian and the dieselFoam solver as well.

When I try to calc the aachenBomb case (dieselFoam solver) there is only one file (positions) in the lagrangian directory! I think the workaround above should fix this problem?

Any help is very appreciated

[niklas]

And did you recompile dieselSpray?

[stefanke]

yes I do!

I recompile the following

liblagrangian
libdieselSpray

and the solver dieselFoam

but there is no more data than position in the lagrangian directory!

[stefanke]

Niklas,

the problem with the "empty" (only postion file is present) lagrangian directory occurs only running the solver in parallel!

[niklas]

reconstructPar depends on Cloud.H.
Did you recompile that code?

[stefanke]

I recompiled the hole OpenFoam!

Anyway the solver abosts in paralell after a certain time

It seems to be impossible to run dieselFoam or dieselEngineFoam in parallel!

[niklas]

Ive just tested dieselFoam on the aachenBomb case in parallel and it works.
dieselEngineFoam should also work (in principle).
The scania case you took from my page is a different matter.
That page is just my personal file transfer page and
if you take something without asking and it doesnt work you have yourself to blame.
I have never claimed it to work and there is a reason I didnt make the case public you know.

N