Hi all, When trying to run
 

Hi all,

When trying to run dieselFoam, get this:

Exec : dieselFoam /home/ervin/OpenFOAM/ervin-1.0.2/run/tutorials/dieselFoam spray1
Date : Mar 14 2005
Time : 10:55:18
Host : isi014.mot.upv.es
PID : 3792
Root : /home/ervin/OpenFOAM/ervin-1.0.2/run/tutorials/dieselFoam
Case : spray1
Nprocs : 1
Create database

Create mesh for time = 0


Reading thermophysicalProperties
Selecting thermodynamics package hMixtureThermo<reactingmixture>
Selecting chemistryReader chemkinReader
Reading field U

Reading/calculating face flux field phi

Creating turbulence model.

Selecting turbulence model RNGkEpsilon
Creating field DpDt

Constructing chemical mechanism
Selecting ODE solver SIBS
chemistryModel::chemistryModel: Number of species = 5 and reactions = 1

Reading environmentalProperties
Reading combustion properties

Constructing Spray
Selecting injectorType unitInjector
Selecting atomizationModel blobsSheetAtomization
Selecting dragModel standardDragModel
Selecting evaporationModel off
Selecting heatTransferModel RanzMarshall
Selecting wallModel reflect
Selecting breakupModel ReitzKHRT
Selecting collisionModel trajectory
Selecting dispersionModel off
Selecting injectorModel constInjector
Average Velocity for injector 0: 357.207 m/s, injection pressure = 591.789 bar
Constructing two dimensional spray injection.Calculated angle of wedge is 4.99791 deg.

Max Courant Number = 0

Starting time loop


Max Courant Number = 0
deltaT = 5e-06

Time = 5e-06
Evolving Spray


... and ... nothing; it doesn't run.


My controlDict is:

// Foam Application Class
applicationClass dieselFoam;

// Start point of run
startFrom startTime;

// Calculation start time
startTime 0;

// End point of run
stopAt endTime;

// Calculation end time
endTime 0.002;

// Calculation time step
deltaT 2.5e-06;

// Type of write output control
writeControl timeStep;

// Interval with which the results are output
writeInterval 40;

// Limits number of time directories before overwriting
cycleWrite 0;

// Write Format
writeFormat ascii;

// Significant figures of written ASCII data
writePrecision 6;

// Write Compression
writeCompression uncompressed;

// Time directories name format
timeFormat general;

// Decimal precision of time directory names
timePrecision 6;

// Can parameters be modified during run time?
runTimeModifiable yes;

adjustTimeStep yes;

maxCo 1.0;

Can you please help me out?

Thanks

Ervin

I have just run the dieselFoam
 

I have just run the dieselFoam tutorial case with OpenFOAM-1.1 and it ran fine.

Hi, Now I have installed Op
 

Hi,

Now I have installed OpenFOAM-1.1 and I still got the same problems of missing entries in the dieselFOAM - aachenBomb case as in 1.0.2.

I have installed OpenFOAM-1.1 as it sais on the web page and readme.

When opening FoamX get these errors:

Non-optional dictionary entry 'runTimeModifiable' not found in dictionary
/home/ervin/OpenFOAM/ervin-1.0.2/run/tutorials/dieselFoam/aachenBomb/system/cont rolDict
in file /home/ervin/OpenFOAM/ervin-1.0.2/run/tutorials/dieselFoam/aachenBomb/system/cont rolDict
start at line 25 ending at line 55

Non-optional dictionary entry 'div((phi|interpolate(rho)),p)' not found in dictionary
/home/ervin/OpenFOAM/ervin-1.0.2/run/tutorials/dieselFoam/aachenBomb/system/fvSc hemes::divSchemes
in file /home/ervin/OpenFOAM/ervin-1.0.2/run/tutorials/dieselFoam/aachenBomb/system/fvSc hemes::divSchemes
start at line 38 ending at line 51

... etc.

How is it possible? What am I doing wrong?

Thank for your help

Ervin

The foamInstallationTest is th
 

The foamInstallationTest is this:

Checking basic setup...
-------------------------------------------------------------------------------
Shell: bash
Host: isi014.mot.upv.es
OS: Linux version 2.6.3-7mdk
User: ervin
User_config: /home/ervin/.bashrc
Foam_config: /home/ervin/.OpenFOAM-1.1/bashrc sourced correctly.
-------------------------------------------------------------------------------


Checking main FOAM env variables...
-------------------------------------------------------------------------------
Environment_variable Set_to_file_or_directory Valid Crit
-------------------------------------------------------------------------------
$WM_PROJECT_INST_DIR /home/ervin/OpenFOAM yes yes
$WM_PROJECT_USER_DIR /home/ervin/OpenFOAM/ervin-1.1 yes no
$FOAM_JOB_DIR /home/ervin/OpenFOAM/jobControl no yes
-------------------------------------------------------------------------------


Checking the FOAM env variables set on the PATH...
-------------------------------------------------------------------------------
Environment_variable Set_to_file_or_directory Valid Path Crit
-------------------------------------------------------------------------------
$WM_PROJECT_DIR /home/ervin/OpenFOAM/OpenFOAM-1.1 yes yes yes

$FOAM_USER_APPBIN .../ervin-1.1/applications/bin/linuxOpt yes yes no
$FOAM_APPBIN ...enFOAM-1.1/applications/bin/linuxOpt yes yes yes
$WM_DIR /home/ervin/OpenFOAM/OpenFOAM-1.1/wmake yes yes yes
$FOAMX_PATH ...ations/utilities/preProcessing/FoamX yes no yes
$CEI_HOME /usr/local/ensight/CEI no no

$JAVA_PATH /home/ervin/OpenFOAM/linux/j2sdk1.4.2_05 yes yes no
$MICO_ARCH_PATH ...1/src/mico-2.3.11/platforms/linuxOpt yes yes yes
$LAM_ARCH_PATH ...1.1/src/lam-7.1.1/platforms/linuxOpt yes yes yes
$MPICH_ARCH_PATH --------- env variable not set --------- no
-------------------------------------------------------------------------------


Checking the FOAM env variables set on the LD_LIBRARY_PATH...
-------------------------------------------------------------------------------
Environment_variable Set_to_file_or_directory Valid Path Crit
-------------------------------------------------------------------------------
$FOAM_LIBBIN ...n/OpenFOAM/OpenFOAM-1.1/lib/linuxOpt yes yes yes
$FOAM_USER_LIBBIN ...rvin/OpenFOAM/ervin-1.1/lib/linuxOpt yes yes no
$LAM_ARCH_PATH ...1.1/src/lam-7.1.1/platforms/linuxOpt yes yes yes
-------------------------------------------------------------------------------


Software versions
-------------------------------------------------------------------------------
Software Version Location
-------------------------------------------------------------------------------
gcc 3.4.3 /home/ervin/OpenFOAM/linux/gcc-3.4.3/bin/gcc
java 1.4.2_05 /home/ervin/OpenFOAM/linux/j2sdk1.4.2_05/bin/java
gzip 1.2.4 (18 Aug 93)
Compilation options:
DIRENT UTIME STDC_HEADERS HAVE_UNISTD_H
gzip /usr/bin/gzip
tar /bin/tar
icoFoam ...penFOAM/OpenFOAM-1.1/applications/bin/linuxOpt/icoFoam
-------------------------------------------------------------------------------


Checking file/directory permissions...
-------------------------------------------------------------------------------
File/directory Set Reqd Crit
-------------------------------------------------------------------------------


Checking networking...
-------------------------------------------------------------------------------
Action Result Crit
-------------------------------------------------------------------------------
Pinging_isi014.mot.upv.es Successful yes
Pinging_localHost Successful yes
Test_rsh: Unsuccessful_connection_refused* yes
Test_ssh: Successful yes
(*) Only one of rsh or ssh is required by the Foam enviroment.

-------------------------------------------------------------------------------

Base configuration ok.

Critical systems ok.


Ervin

The aachenBomb tutorial has no
 

The aachenBomb tutorial has not been corrected for FoamX although it does run fine, try the Allrun script to check it on your machine.

The problems with this tutorial and FoamX have been reported before and I was told I would receive a set of correction for it but they have not been posted to my knowledge and hence not included in the 1.1 release. As soon as I receive the corrected files I will include them for the next release.

Hello Henry, It's running.
 

Hello Henry,

It's running.
Thanks for this tip. Now I understand.
The one who said that will correct this case for FoamX was me, but I couldn't finish it yet.

So, one more question:
If the case is running correctly from the command line it means that the entries in these tutorial files are correct and the FoamX configuration file needs to be modified? Which one is it?

Thank you

Ervin

FoamX show there are missing e
 

FoamX show there are missing entries in the tutorial files as indicated by the error messages but the code can still run because these entries are optional and default values are assumed if they are not present. FoamX does not currently have a concept of optional entries in dictionaries and so they must be complete. Unfortunately this tutorial was created by someone who does not use FoamX (you can own-up if your want to, we know who you are...) and all the dictionaries were written by hand starting from an existing case and so no checking was done to make sure it was compatible with FoamX.

Now that we have a large number of users I hope these error will be found and corrected quickly for the benefit of all future users.

Or, if the case has to be corr
 

Or, if the case has to be corrected, than I was adding the missing entries in the dictionary files of the case, but I don't know the values for some. For example: ft, fu, A.

Thanks

OK. Thanks Ervin
 

OK.

Thanks

Ervin

OK, I will take a look at it l
 

OK, I will take a look at it later and post the necessary changes.

The current FoamX configuratio
 

The current FoamX configuration files for dieselFoam correspond to a very old version which used a very simple combustion model. The new dieselFoam supplied by Niklas Nordin user his multicomponent mixture spray model and a combustion model including complex chemistry. Unfortunately no one has had the time to update the FoamX configuration files for these developments and it looks like a substantial effort because not even the current spray modelling has up-to-date FoamX support. So unless you are someone else has the time to spend on the task of updating the FoamX configuration files users of dieselFoam will have to edit the contol dictionaries by hand at least for now.

Hi Guys I need a help. I'm
 

Hi Guys

I need a help. I'm testing the dieselFoam solver with the aachenBomb tutorial case and I have problems trying to restart it. If I put to run with the controldict such that:

startFrom firstTime;

I have not problem and the case runs. But when I put the case to restart using, for example:

startFrom startTime;

startTime 5e-05;

The solver crashes and the following message apears in the output.

==========================================
.
.
.

Evolving Spray

--> FOAM FATAL ERROR : attempt to use janafThermo<equationofstate> out of temperature range 200 -> 5000; T = 1.46567e+161

From function janafThermo<equationofstate>::checkT(const scalar T) const
in file /home/dm2/henry/OpenFOAM/OpenFOAM-1.2/src/thermophysicalModels/specie/lnInclude/ janafThermoI.H at line 73.

FOAM aborting
======================================

I tested using either binary as ascii writeformat and both does not work. Could somebody help me?

Many tanks in advance

Wladimyr

hi! I am running the aachen b
 

hi!
I am running the aachen bomb tutorial. the Time is now 0.015 and the CO2 file in time directories(eg 0.0149) shows nothing. I think there is no reaction in this case(is it right?). only a reduction in temperature(caused by evaporation)
thank you for your time

hi! I am running the aachen b
 

hi!
I am running the aachen bomb tutorial. the Time is now 0.015 and the CO2 file in time directories(eg 0.0149) shows nothing. I think there is no reaction in this case(is it right?). only a reduction in temperature(caused by evaporation)
thank you for your time

sorry it works the chemistry
 

sorry
it works
the chemistry was off
sorry

Did anyone manage to post-proc
 

Did anyone manage to post-process the spray-particles when working with the 1.2 version? When running dieselFoam v1.2 on the aachenBomb tutorial the only file that is written to the lagrangian-subDirectories of the time directories is positions. When running v1.1 on the same case (fvSchemes had to be replaced) a lot more files get written (T, U etc).

If there is only a positions-file foamToVTK doesn'T create any data for the particles (which is OK, because the positions alone are not very interesting). Without that data they can't be visualized (of course)

Is this non-creation of files a problem of

* the lagrangian code in the library
* dieselFoam itself
* wrong configuration in the tutorial

There should be no difference
 

There should be no difference between 1.1 lagrangian data and 1.2. So it still should write mulitple files to the lagrangian/ directory.

Sounds like the tutorial configuration is different.

Can you figure out what is going wrong and send an update?

I didn't stress that enough in
 

I didn't stress that enough in my first posting: I ran the v1.1-dieselFoam on the v1.2-case (I just replaced the fvSchemes-file with the one from the v1.1-tutorial) and it worked.

I compared the two tutorials anyway and the only significant change seems to be in thermophysicalProperties: burntProducts1 and stoechiometricAirFuelMassRatio1 were removed
(but as the v1.1-solver has no problem with that I think it wasn't important in v1.1)

I compared the diesel(Engine)F
 

I compared the diesel(Engine)Foam-solver code too. I didn't find any changes there that I would blame for that problem.

I then compared the src/lagrangian-files from the 1.1 and the 1.2 distribution and stumbled upon the following thing in parcelIO.C (apart from that I didn't find any changes of interest for that particular problem):

The Cloud<parcel>::readFields() and Cloud<parcel>::writeFields() (which seem to be in charge of outputing the missing fields) are marked as template specialisations (with template<>) in the new release.

Could this be the problem?

Should not be a problem. Is ju
 

Should not be a problem. Is just for some compilers' sake.

Have you tried putting some Info statements in there to see if they get called? Or compile with debug and run through ddd/gdb and sprinkle some breakpoints around.

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