To be honest I'm still working
 

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 ...)

It's happening to me too. In t
 

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

My mistake. The output in the
 

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.

I think I've found the mistake
 

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

maybe this wasnt such a brilli
 

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

N

Nope, not a good idea... but I
 

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

ok, this works... as above
 

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

> is this acceptable? nope...
 

> 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.

My guess (but it's a long time
 

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?

Sorry for my garbage. I didn't
 

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

Maybe it's not the right topic
 

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.

nice! So what are you using it
 

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

Myself I'm not using it. I did
 

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.

Hi, I try to fix the bug in
 

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

And did you recompile dieselSp
 

And did you recompile dieselSpray?

yes I do! I recompile the f
 

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!

Niklas, the problem with th
 

Niklas,

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

reconstructPar depends on Clou
 

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

I recompiled the hole OpenFoam
 

I recompiled the hole OpenFoam!

Anyway the solver abosts in paralell after a certain time http://www.cfd-online.com/OpenFOAM_D...lipart/sad.gif

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

Ive just tested dieselFoam on
 

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