CFD Online Logo CFD Online URL
www.cfd-online.com
[Sponsors]
Home > Forums > OpenFOAM Running, Solving & CFD

dieselSpray class and diesel/dieselEngineFoam in OF 2.1.x

Register Blogs Members List Search Today's Posts Mark Forums Read

Like Tree2Likes
  • 1 Post By mturcios777
  • 1 Post By niklas

Reply
 
LinkBack Thread Tools Display Modes
Old   January 13, 2012, 14:08
Default dieselSpray class and diesel/dieselEngineFoam in OF 2.1.x
  #1
Senior Member
 
mturcios777's Avatar
 
Marco A. Turcios
Join Date: Mar 2009
Location: Vancouver, BC, Canada
Posts: 725
Rep Power: 18
mturcios777 will become famous soon enough
Downloaded the latest release through the git repository and these all appear to be missing. Is this just me, and if not why are they gone?
mturcios777 is offline   Reply With Quote

Old   January 19, 2012, 17:30
Default
  #2
Senior Member
 
mturcios777's Avatar
 
Marco A. Turcios
Join Date: Mar 2009
Location: Vancouver, BC, Canada
Posts: 725
Rep Power: 18
mturcios777 will become famous soon enough
Figured I'd answer my own question so if people stumble on this thread they can get information, and to continue the discussion begun in this thread (apologies in advance for the long post). The dieselSpray class has been deprecated by including its functionality into the generalized lagrangian spray libraries. This happened in OF 2.0.x: New Langrangian Functionality, look at the subsection "Migration of DieselSpray"

The new lagrangian spray classes are used in the solvers like:
reactingParcelFoam
sprayFoam
sprayEngineFoam

Currently they are formulated to only have one spray, via the constructor (in this case, for sprayFoam)
Code:
Info<< "\nConstructing reacting cloud" << endl;
basicSprayCloud parcels
(
    "sprayCloud",
    rho,
    U,
    g,
    slgThermo
);
When running a case, there needs to be a dictionary called sprayCloudProperties in the constant directory that describes the spray. Currently it appears the solver can only use one spray. It may be possible to use more by something like:
Code:
 scalar sprayNum(readScalar(controlDict.lookup("sprayNum")));
PtrList<basicSprayCloud> sprays(sprayNum);

forAll(sprays,sprayI)
{
    OStringStream num;
    num << i;
    word sprayName = "sprayCloud" + num.str();
    sprays.set
    (
        sprayI,
        new basicSprayCloud
        (
            sprayName,
            rho,
            U,
            g,
            slgThermo
        )
    );
}
I used some of Niklas's code from this thread. Now you need a series of files called sprayCloud0Properties, sprayCloud1Properties, ..., sprayCloud{n-1}Properties. Maybe this could be pushed into the main solver, or another solver like multiSprayFoam? Also, there needs to be a step where you add up all the source terms for transport equation solving, for rhoEqn.H for example
Code:
fVScalarMatrix rhoSource; //I'm not sure how to initialize this. Can I make this a volumeScalarField?

forAll(sprays,i)
{
    rhoSource+= sprays[i].Srho(rho); //I think this should be right, but not 100%
}

{
    solve
    (
        fvm::ddt(rho)
      + fvc::div(phi)
      ==
        rhoSource
    );
}
All sprays will use the same slgThermo, and not knowing enough about this new way of doing this I don't know if this is desirable or not. Please comment and let me know if anything in here is wrong or inefficient and I'll get some tests run.
ayhan515 likes this.
mturcios777 is offline   Reply With Quote

Old   January 19, 2012, 20:01
Default
  #3
Senior Member
 
mturcios777's Avatar
 
Marco A. Turcios
Join Date: Mar 2009
Location: Vancouver, BC, Canada
Posts: 725
Rep Power: 18
mturcios777 will become famous soon enough
Before that though, it appears that there may be a bug in sprayFoam (and by extension reactingParcelFoam as the transport equations all originate there). In the included aachenBomb tutorial case, injection or the parcels works, though it appears that only N2 is displaced; the O2 field remains uniform at 0.234. Can someone verify this behaviour independently?

EDIT: I've confirmed this behaviour on two different machines, seems the change occured in OF2.1x. I've filed a bug report, I'll look though the solver and lagrangian libraries and see if I can come up with anything useful.

Last edited by mturcios777; January 20, 2012 at 14:36. Reason: Additional information
mturcios777 is offline   Reply With Quote

Old   January 24, 2012, 07:09
Default
  #4
Super Moderator
 
niklas's Avatar
 
Niklas Nordin
Join Date: Mar 2009
Location: Stockholm, Sweden
Posts: 693
Rep Power: 19
niklas will become famous soon enough
Yeah, I saw the bug-report this morning and the problem was in the Make/options file.
Seems like the order of the includes was wrong so it picked up the rhoEqn from the
wrong place (this didnt have a source term for the evaporation).

solution is to place the
-I$(FOAM_SOLVERS)/lagrangian/reactingParcelFoam \

at the first position.
cheers,
N
niklas is offline   Reply With Quote

Old   January 24, 2012, 14:26
Default
  #5
Senior Member
 
mturcios777's Avatar
 
Marco A. Turcios
Join Date: Mar 2009
Location: Vancouver, BC, Canada
Posts: 725
Rep Power: 18
mturcios777 will become famous soon enough
Thanks Niklas, it works perfectly now! I have a question that you may be able to answer. In my solver I am keeping track of a conserved scalar whose source term comes from the evaporation of a species in the spray. If I have the index of the species (iC7H16), I used to be able to add the following to the transport equation:

Code:
 solve
{
//transport with the usual advection/diffusion terms
==
dieselSpray.evaporationSource(iC7H16)
}
With the change in the libraries, I thought the equivalent call for a basicSprayCloud would be

Code:
 volScalarField& beta = Y[iC7H16];

solve
{
//transport equation has the usual advection/diffusion terms
==
parcels.SYi(iC7H16,beta)
}
The code compiles, but at runtime I get the error:

Code:
--> FOAM FATAL ERROR: 
incompatible fields for operation 
    [beta] == [C7H16]

    From function checkMethod(const fvMatrix<Type>&, const fvMatrix<Type>&)
    in file /home/mturcios/OpenFOAM/OpenFOAM-2.1.x/src/finiteVolume/lnInclude/fvMatrix.C at line 1300.
It seems there is some more consistency checking going on (which I guess is good), but I'm not sure how to work around this without breaking Foam. Any suggestions? Maybe I need to cast the returned function as a generic source term? Thanks in advance!

Last edited by mturcios777; January 24, 2012 at 14:28. Reason: Spelling and clarity
mturcios777 is offline   Reply With Quote

Old   January 24, 2012, 15:32
Default
  #6
Super Moderator
 
niklas's Avatar
 
Niklas Nordin
Join Date: Mar 2009
Location: Stockholm, Sweden
Posts: 693
Rep Power: 19
niklas will become famous soon enough
the parcel.SYi is no longer just a source term, but a fvScalarMatrix.
Thats why you can't just add it anymore, since it actually checks that
you are adding apples with apples.
That means you also can make the source a mix of explicit/implicit, by the coefficient
in the sourceTerms dictionary.

To extract the source part, ie. the explicit part you can do something like this
Code:
    volScalarField parcelSource
    (
        IOobject
        (
            "parcelSource",
            mesh.time().timeName(),
            mesh,
            IOobject::NO_READ,
            IOobject::NO_WRITE
        ),
        mesh,
        dimensionedScalar("zero", dimMass/dimTime/dimVolume, 0.0)
     );

    fvScalarMatrix parcelEq(parcels.SYi(i, Yi));
    scalarField source(parcelEq.source());
    parcelSource.internalField() = source;
and then add parcelSource to the transport equation 'as usual'
mturcios777 likes this.
niklas is offline   Reply With Quote

Old   January 24, 2012, 16:00
Default
  #7
Senior Member
 
mturcios777's Avatar
 
Marco A. Turcios
Join Date: Mar 2009
Location: Vancouver, BC, Canada
Posts: 725
Rep Power: 18
mturcios777 will become famous soon enough
Many thanks Niklas! To tie up the questions in this thread, how should multiple injectors be handled under the new lagrangian libraries. For immediate consideration I have two sprays which isn't hard to implement manually (i.e., include each spray explicitly in the transport equations), but for more than that a fully general one would be very nice. Or have I misunderstood the library/solvers and is the the ability to have multiple injectors already present?

Last edited by mturcios777; January 24, 2012 at 16:19. Reason: Posted injector questions to fully resolve thread.
mturcios777 is offline   Reply With Quote

Old   January 24, 2012, 16:42
Default
  #8
Super Moderator
 
niklas's Avatar
 
Niklas Nordin
Join Date: Mar 2009
Location: Stockholm, Sweden
Posts: 693
Rep Power: 19
niklas will become famous soon enough
No its not possible at the moment.

But when you say multiple injectors, do you actually mean that or just multiple
injection positions.

Because there is a slight difference, since the latter is possible and pretty straightforward.
Just add a multipleInjectors injector.

The problem with doing it the way you describe is that there will be no interaction
between the different 'injectors', so if you want to have collisions and let the
parcels exchange mass, its not possible.

I've talked to Andy about this and he has an idea how he wants to do it, but he hasn't added the feature yet.
niklas is offline   Reply With Quote

Old   January 24, 2012, 19:21
Default
  #9
Senior Member
 
mturcios777's Avatar
 
Marco A. Turcios
Join Date: Mar 2009
Location: Vancouver, BC, Canada
Posts: 725
Rep Power: 18
mturcios777 will become famous soon enough
Both actually. I see what you mean about the interaction problem. Right now it isn't a huge problem as I don't *need* droplet interaction that much (and the old dieselSpray library still compiles under OF21x for when we go), but it would be nice to migrate to this new completely general formulation, and plus the ddtPhiCorr method for dynamic meshes will become much more important to us as we move forward.

I'm testing out the code I posted earlier and it works ok so far. I'm working on getting behavior similar to the old commonRailInjector, but since all my questions have been answered from this thread I'll start a new one and link to it: here it is.
mturcios777 is offline   Reply With Quote

Old   January 26, 2012, 19:31
Default
  #10
Senior Member
 
mturcios777's Avatar
 
Marco A. Turcios
Join Date: Mar 2009
Location: Vancouver, BC, Canada
Posts: 725
Rep Power: 18
mturcios777 will become famous soon enough
The code posted by Niklas works very well. While rooting around the new lagrangian libraries while contemplating multiple injectors, I noticed the following class ReactingLookupTableInjection, which looks like it does multiple injection sites, albeit with a much more manual approach. Could this be adapted to give multiple injectors?
mturcios777 is offline   Reply With Quote

Old   February 7, 2012, 00:55
Default
  #11
Member
 
Abhishek
Join Date: Dec 2010
Posts: 38
Rep Power: 6
Abhishekd18 is on a distinguished road
Hi,

I am facing problem with dieselFoam 1.6 ext. I am getting janaf error. Temperature in some of the cells drops below 200. These cells are located where there is injection. So, I think it may be due to droplets absorbing excessive heat from surrounding. I tried reducing max Courant number to 0.01 and started with very less time step. I also tried with finer mesh. Still, I am not able to get rid of the error.

However, the same setup with same boundary conditions works perfectly fine with OpenFoam 2.0.

Can anyone help me on this?
Abhishekd18 is offline   Reply With Quote

Old   February 7, 2012, 05:03
Default
  #12
New Member
 
Join Date: Jul 2011
Posts: 1
Rep Power: 0
amfortas is on a distinguished road
Hi Abhishek,

I am facing the same problem with 1.6-ext. After a while searching I found that there are a bug:

http://sourceforge.net/apps/mantisbt...view.php?id=46

which is still unresolved.
I am working actually with OF-1.5-dev which also includes some dynamic mesh features.

Alex
amfortas is offline   Reply With Quote

Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
thobois class engineTopoChangerMesh error Peter_600 OpenFOAM 4 August 2, 2014 09:52
member function [value()] of dimensioned<Type> class sblee1977 OpenFOAM Programming & Development 2 November 9, 2010 04:52
Errors running allwmake in OpenFOAM141dev with WM_COMPILE_OPTION%3ddebug unoder OpenFOAM Installation 11 January 30, 2008 21:30
About UList and List class leosding OpenFOAM Running, Solving & CFD 1 December 2, 2005 00:52
Expanding a class fabianpk OpenFOAM 0 October 3, 2005 04:26


All times are GMT -4. The time now is 14:33.