CFD Online Discussion Forums

CFD Online Discussion Forums (http://www.cfd-online.com/Forums/)
-   OpenFOAM Programming & Development (http://www.cfd-online.com/Forums/openfoam-programming-development/)
-   -   Time-varying gravity in interFoam (http://www.cfd-online.com/Forums/openfoam-programming-development/124544-time-varying-gravity-interfoam.html)

gradylemoine October 7, 2013 17:53

Time-varying gravity in interFoam
 
Hi all,

I'm trying to model waves generated in a wave flume by a piston-type wave maker. I've decided the numerically simplest way to do this is probably to just do the modeling in the reference frame of the piston face, which is equivalent to having gravity vary with time. I took a look at a previous post on these forums on how to do this, http://www.cfd-online.com/Forums/ope...vity-time.html, but things seem to have changed a little bit in the OpenFOAM codebase since then.

I've successfully gotten my time-varying gravity vector into the solver, and am re-evaluating g at each timestep in interFoam.C, but it seems that gravity gets into the solution process through the gh and ghf fields, not through g itself. It looks like I need to recompute gh and ghf at each timestep after I re-evaluate g.

My questions are:

1. Is this a sound approach -- would I be violating any assumptions in interFoam by having gh and ghf change at each timestep, and is updating them all I need to do to get the new gravity into the solve for each timestep?

2. I'm a little rusty at C++; how do I update these fields without causing a memory leak? Should I call the destructor on the old objects, then make completely new ones, or is there some other way I should do the updates?

Regards,

--Grady Lemoine

Phicau October 8, 2013 05:33

Hi Grady,

I think your approach is not suitable in this case, as changing the gravity will affect the whole domain. Then, instead of obtaining a piston-type wave maker, you would be obtaining a sloshing tank. To obtain the required behaviour you would need a very specific outlet boundary condition.

I think mesh movement to compress and stretch the domain will be easier and more suitable for your purposes.

Best,

Pablo

gradylemoine October 8, 2013 11:53

Moving meshes actually sounded too hard to me; I've never worked with them, and they have a reputation of being computationally expensive. I figured a sloshing tank is actually equivalent to a piston wave maker -- I'm just doing the analysis in the reference frame of the piston face, not an inertial frame. After I have the basics working, I'll add time-varying floor velocity and a time-varying inlet, since my plan is just to model the part of the wave flume directly in front of the piston -- just a long enough section that the waves don't reach the other end of the domain before the simulation ends.

I got this working yesterday after I posted, but I still need to do some verification to make sure I'm getting correct solutions, and I also need to check for memory leaks. Here's what I'm doing in the timestepping loop to update the gravity:

// Evaluate time-varying gravity
if (useTimeVaryingGravity)
{
double gEvalTime = runTime.value() - 0.5*runTime.deltaTValue();
Info << "Evaluating gravity at time " << gEvalTime << nl << endl;

// This leaks memory, but it's only leaking one vector per
// time step so it shouldn't be a problem.
// timeVaryingGravity is an interpolationTable<vector> object.
g = dimensionedVector("g", g.dimensions(), (*timeVaryingGravity)(gEvalTime));

Info << "Using gravity: " << g << " evaluated at time " << gEvalTime << nl << endl;

// Re-create gh, ghf fields
gh = volScalarField("gh", g & mesh.C());
ghf = surfaceScalarField("ghf", g & mesh.Cf());
// Is this OK?
}

I can accept leaking a vector's worth of memory at every timestep, if that's going to happen with this code, but will those last two lines that re-create gh and ghf result in a memory leak?

Regards,

--Grady Lemoine


All times are GMT -4. The time now is 23:39.