|
[Sponsors] |
![]() |
![]() |
#1 |
New Member
Grady Lemoine
Join Date: Oct 2013
Posts: 7
Rep Power: 12 ![]() |
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 |
|
![]() |
![]() |
![]() |
![]() |
#2 |
Senior Member
Pablo Higuera
Join Date: Jan 2011
Location: Auckland
Posts: 627
Rep Power: 19 ![]() |
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 |
|
![]() |
![]() |
![]() |
![]() |
#3 |
New Member
Grady Lemoine
Join Date: Oct 2013
Posts: 7
Rep Power: 12 ![]() |
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 |
|
![]() |
![]() |
![]() |
Tags |
gravity, memory management, wave flume |
|
|
![]() |
||||
Thread | Thread Starter | Forum | Replies | Last Post |
AMI speed performance | danny123 | OpenFOAM | 21 | October 24, 2020 04:13 |
High Courant Number @ icoFoam | Artex85 | OpenFOAM Running, Solving & CFD | 11 | February 16, 2017 13:40 |
Unstabil Simulation with chtMultiRegionFoam | mbay101 | OpenFOAM Running, Solving & CFD | 13 | December 28, 2013 13:12 |
pisoFoam with k-epsilon turb blows up - Some questions | Heroic | OpenFOAM Running, Solving & CFD | 26 | December 17, 2012 03:34 |
interFoam case blows up | jrrygg | OpenFOAM Running, Solving & CFD | 8 | November 14, 2012 03:16 |