Greetings Dave,

Thanks for your feedback - did you have some particular problems, if so, could I convince you to make a small section at the Wiki in order to help others using 2.1 with waves2Foam?

With respect to your questions, I will answer it in several steps, as the question itself have several layers in it:

1. You do not need to use setWaveField at all. I have merely included this utility for two reasons:
1.a. It makes the initialisation of a still water level more correct, if the cells are not aligned with the location of the free surface. At least more correct in terms of mass conservation, however, you will still experience the standard spurious velocities in the air.
1.b. Say that you want first order Stokes waves in the entire domain and the bed is horizontal, then one can save computational time by using setWaveField to have the hydrodynamics initialised to that given wave theory in the entire domain.

2. Stability issues using (the utility) setWaveField with a moving ship.
In this case, you have to look into the file src/setWaveField/setWaveField.C which is the one, which is utilised in setWaveField for the initialisation. I am currently not at a computer with waves2Foam, so I cannot answer your question explicitly. Nevertheless, as I recall the implementation, setWaveField.C (the class, there is a bit of naming confusion here), calls the waveTheory, which is specified through waveProperties, to be used for the initilisation. If the computational cell is above the free surface, I believe the velocity is explicitly set to zero in setWaveField.C.

3. During runTime, the same thing happens for the relaxation zones. Here, the easiest thing for you might be to derive a new class from relaxationScheme, which calls a variable from waveProperties.subDict, say shipVelocity, and sets the velocity in the air to this given velocity. Or you could get the velocity from either the boundary condition of the ship, or where ever.

4. The conflict between 2 and 3 might be solvable, however, this would require any of two things:
4.a. Let setWaveField.C (the class) call autoPtr to relaxationScheme rather than waveTheory. However, in this case the user has to remember that the defined extend of the relaxation zone should span the entire domain! I do not like such "and please remember that you have to do this in this particular case".
4.b. Have a special constructor in relaxationScheme, which do not look into waveProperties for the spatial extend of the relaxation, but automatically uses the entire domain, i.e. all of the computational cells, and which to do not weight the 'computed' solution with a target, but uses the target directly. This might actually be a good approach, however, as I said my waves2Foam is one computer away, so I have to look at this on Monday. The benefit of this would be that you could use your derived class with the ship velocity in the initialisation without any manual interaction.

5. The golden version would be to have a accompanying 'airTheories' abstract class, which is called, and if the user do not care about the air velocities, then an 'empty' (= vector::zero) is returned for the air velocity, whereas non-zero velocities are returned in other cases.

I hope that this fully answers your questions and thank you for the feedback. I am sincerely happy to receive any comments, suggestions, submissions, etc.

Kind regards,

Niels

Niels,
Thanks, for your response. My compiling issues were really just related to the option file when I went to create my own waveFoam in a different location other then within wave2Foam and not an issue caused by the wave2Foam package itself (which compiled on the first try). I was a little confused about where to put the wave2Foam folder since when I got it off sourceforge it placed it in my home directory so I moved it to the applications folder before compiling it.

I went back and found the places where the air velocity is set to zero as you pointed out. I think I may add vector definition in one of the dictionary files (was thinking waveProperties as well) and replace the instances of the vector: UTarget(vector::zero);

with the user defined vector: UTarget(windvector);
along with the equivalent line in RelaxationSchemeSpatial.C

If still air is desired by the user, then the vector can simply be set equal to (0 0 0). By making it user defined it also allows for wind in any direction to be specified. Where I could see an "airTheories" class coming in handy is if a wind velocity profile was desired though I can't imagine that would be easy to do for an inlet with waves present.

The meaning of waveVelocity BC parameters is a little confusing. The choice of "value" versus "refvalue" is not entirely clear to me along with valueFraction.
inlet
}
type waveVelocity;
refValue uniform ( 0 0 0 );
refGradient uniform ( 0 0 0 );
valueFraction uniform 1;
value uniform (0 0 0);
}


Dave

Hi Dave

Yes, your approach seems, at least at the moment, to be the simplest modification to the source code. After looking through the code yesterday, I have become unhappy with the reappearance of the same piece of code in both setWaveField and relaxationScheme, so I might end up making a more general implementation at some point, when I have figured out the structure.

You could even make a lookupOrDefault, where the default value is a vector::zero. In this way, the user only needs to specify the velocity, if needed. When you have got it working, could I convince you to make a submit or send me a patch-file; I will obviously give you the proper acknowledgement.

Yes, wave/air flow is a difficult topic and finding some expressions to use for the air flow is not straight forward, however, the point was raised in the review of the article, which we have published on waves2Foam :)

With respect to the value and refValue, those are needed by mixedFvField<Type>, which is the parent class of the wave***** boundaryConditions. It does essentially not matter what you specify, as the values will be overwritten in the very first time step.

Kind regards,

Niels

Niels,
Yes, there is certainly a great deal of repeated code. I count 3 instance of gravity being defined (setWaveProperties.C, waveTheory.C, and relaxationShape.C) with a lot of other similar code in those files. It may make sense to create a class which does all of the reading from waveProperties to condense all of that repeated code. I have gone ahead and added a wind vector in all of the relevant places with an input in the waveProperties file. I have not added the lookupOrDefault functionality since I am unfamiliar with how to do that in this context. If you have any examples of it that you can point to in OpenFOAM I can go ahead and add it. I have not checked if this works with version 1.5 though I don't believe I have done anything that should make it incompatible. I have made modifications to the following:
waveTheory.H/C
setWaveField.H/C
relaxationSchemeSpatial.H/C

I will send you a message with my email and will send a tar file of the changed files once I confirm that the results appear correct (currently running).

Dave

Hi Dave

You will need something like

with the meaning:

Silvan

PS: If your class is not derived from IOdictionary try myDict_.lookupOrDefault(...)

Silvan,
Thank you, once you pointed out the format it became fairly straight forward to apply. The changes have been made and sent to Niels for incorporation.

Dave

Hi all,

some people asked me about how to couple waves2Foam with dynamic mesh motion. I've wrote a little 'how to' about how do it. You can find it here:

https://sites.google.com/site/jordim...ic-mesh-motion

Best regards,

Jordi.

Hi Jordi

Great :) I keep smiling, whenever someone puts an effort into improving the usability of waves2Foam! Could I convince you to put a section on the wiki and incorporating your description there or simply put a link to your website?

Thanks a lot,

Niels

The wiki is updated ;)

Thanks!

Enjoy this wonderful Thursday,

Niels

Hi Niels,

have you experienced with decomposed cases running in parallel? I've launched a case with a floating 3D box and my surprise is that the waves dissipates in the internal boundaries normal to wave direction!

Here you can see the dissipation effect: http://dl.dropbox.com/u/23292595/floatingBox3DWave.png

Now I'm running the same case with no domain descomposition in x direction to see if that's the problem...

kind regards,

Jordi.

No, I have never, ever seen anything like that!

Is the relaxation zone coinciding with the decomposition boundary?

What version of OF are you using?

The relaxationZone is completely local, so it should not have any problems with decomposed mode. Is the inertia transmitted correctly across the boundary, thus merely a problem with the processor boundary on alpha1, or is both pressure, velocity and alpha1 discontinuous across the processor boundary?

Lots of questions and no answers - sorry.

/ Niels

Hi Niels,

the problem isn't the domain decomposition nor the info exchange between domains. The problem was the lateral walls BC. Since i designed the simulation like a wave channel, first I used zeroGradient for alpha and fixedValue (0 0 0) for U (BCs for a wall..), second i tried with a first zone with lateral walls using waveAlpha and waveVelocity (like 3Dwave case tutorial) followed by a zone with lateral walls using previous BCs, but in the transition zone between BCs the wave dissipates sharply. Only if I use waveAlpha and waveVelocity along the domain the wave cross all the channel... but how to do properly the transition to the relaxation zone?

btw, i use OF1.7.1.

Kind regards,

Jordi.

Okay, I really do not understand what you are saying. Are you modifying the processor boundaries? If that is the case, you should not do that.

Otherwise, you would need to make a sketch of your set-up in order for me to understand.

Have a nice weekend

Niels

Hi Niels,

ok, sorry for my bad explanation :(. As you seen before, the study domain is as follows:

Attachment 11387

The problem I'm having is to set properly the boundary condition of lateral walls. See in the next image an schematic representation of lateral wall divided en three zones (the wave travels fromt left to right):

Attachment 11388

Some setting that I've used:

1. If I use for zones 1, 2 and 3 the b.c. zeroGradient for scalar field alpha1, and fixedValue (0 0 0) for vector field U, then the wave dissiaptes sharply...

2. If i use in zone 1 (or 1 and 2) the bc's waveAlpha and waveVelocity (specifyng the patches as 'inlet'), and for the other lateral patches the bc's specified in point 1, in the transition zone the behaviour of the wave is very unrealistic, the field alpha isn't continous, looks like a cut..

3. Alternatively, I tried setting the bc's for alpha1 and U as waveAlpha and waveVelocity respectively in the three zones, but i'm not sure that's a good option... for example in the outlet zone (zone 3), in the patch the wave is not dissipated, but in the bulk zone is it dissipated.

I hope that with this explanation you can understand better my problem... so...

Sorry if that's a silly question... but which boundary conditions suggest I use? I'm thinking other alternatives, but maybe you can help me to fix it quickly.

Btw, in simulations where exists a transition between patches (as i exposed in point 2) some simulations get suddenly frozen calculating p_rgh, not show any error message, simply the process remains active until you stop it... but the simulation doesn't advance...

Thanks a lot,

Kind regards,

Jordi.

Waves2Foam Related Topics
 

Hi Jordi

I am really confused - not over your explanation - but on what goes wrong. Could you please send me a test case, which exhibits these problems, but please try to make it as small as possible, so the simulation time is kept low.

Yes, I have also experienced problems with the stalling at the pressure equation. I have not found any good reason for it. It happens out of the blue on both static and dynamic meshes.

Kind regards,

Niels

Good afternoon everybody

I am working with the 3Dwaves-tutorial and have a few questions coming up:

1.) seaLevel is set to 0.01, although 0.0 would make sense. However, when I set seaLevel to 0.0 I get a floating point exception after approx. 1.7 seconds. Is there a known reason for this behaviour?

2.) The cell height in 3Dwaves is 0.25 meters, and we are dealing with a wave height of 0.2 meters. I would have expected, that we need a bigger number of cells over the wave height.

3.) When I try to increase the wave height in 3Dwaves from 0.2 to 0.5 I also get a floating point exception after approx. 6 seconds.

Im glad to read your opinions and hints.

Best regards
Silvan

PS: Many thanks to Jordi. I am also working with moving grids and was happy to find your description.

PPS: I am using OF 2.1, the 3Dwaves-tutorial is slightly modified: fvSolution as described in my first post, and I left away the wall since I have problems with createBaffles in OF 2.1.

Hi Silvan

I have just tried to do what you reported, and I can reproduce the problems at this end. I believe the problem is related to the unboundedness of alpha1, see screen dump. These values occur right the corner at one of the inlet zones and the outlet zone (white boxes). It might call for a special boundary condition for the lateral boundaries, but since I have not worked intensively with 3D wave problems, I have not considered whether or not it is a problem. Changing seaLevel to 0.01 apparently keeps the magnitude of the negative number small enough for the simulation to complete.

With respect to the discretisation, it is merely a tutorial used to convey the functionality of waves2Foam, so for real life applications you would indeed need more cells.

Kind regards,

Niels

Hi Niels

Thanks for your reply. I will try around with different discretisations and relaxations zones.

Best regards
Silvan

Hi

I have two suggestions:

1. Try retracting the relaxation zone some distance from the corner in the domain and see what happens.

2. The problem might be that the lateral boundaries are waveTheory-type boundaries, but the relaxation zone does not alter the values at the boundaries, merely in the interior. What is potentially needed is a boundary condition on the lateral boundary, which extrapolate from the relaxed interior values.

All the best,

Niels