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

Questions on dynamicTopoFvMesh

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

Like Tree5Likes

Reply
 
LinkBack Thread Tools Display Modes
Old   February 9, 2015, 11:43
Default
  #61
Senior Member
 
Sandeep Menon
Join Date: Mar 2009
Location: Amherst, MA
Posts: 396
Rep Power: 17
deepsterblue will become famous soon enough
Hello Giancarlo,

Perhaps you could print out your "T" field after mesh.update() and see if the values are within the range that you expect? I'm looking to see if the field remapping after topology changes is correct.

Thanks,
Sandeep
__________________
Sandeep Menon
University of Massachusetts Amherst
https://github.com/smenon
deepsterblue is online now   Reply With Quote

Old   February 9, 2015, 14:28
Post
  #62
New Member
 
Giancarlo
Join Date: Apr 2013
Location: Milan
Posts: 21
Rep Power: 6
Giancarlo_IngChimico is on a distinguished road
Hello Sandeep,
thanks for your reply.
I have checked the temperature field after the mesh.update and the remapping seems to work well.
I insert what I see from the bash

Code:
Create time

Create dynamic mesh for time = 0

Selecting dynamicFvMesh dynamicTopoFvMesh
Selecting metric Knupp
--> FOAM Warning : 
    From function dlLibraryTable::open(const fileName& functionLibName)
    in file db/dlLibraryTable/dlLibraryTable.C at line 85
    could not load libtetMetrics.so: cannot open shared object file: No such file or directory
Selecting motion solver: mesquiteMotionSolver
Selecting quality metric: AspectRatioGamma
Selecting objective function: LPtoP
Selecting optimization algorithm: FeasibleNewton
Outer termination criterion (tcOuter) was not found. Using default values.
Reading field T

Reading transportProperties

Reading diffusivity DT

Time = 0.001
before mesh update  
 * T gas min/max   = 300, 773


************** QualityAssessor(free only) Summary **************

  Evaluating quality for 40521 elements.
  There were no inverted elements detected. 
  No entities had undefined values for any computed metric.

          metric     minimum     average         rms     maximum    std.dev.
AspectRatioGamma  1.00071332 1.251984571 1.262627653 2.5725376290.1635946915

************** QualityAssessor(free only) Summary **************

  Evaluating quality for 40521 elements.
  There were no inverted elements detected. 
  No entities had undefined values for any computed metric.

          metric     minimum     average         rms     maximum    std.dev.
AspectRatioGamma 1.000839219 1.251709074 1.262370641  2.573260010.1637193572

 ~~~ Mesh Quality Statistics ~~~ 
 Min: 0.5325301726
 Max: 0.999440912
 Mean: 0.8683070914
 Cells: 40521
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 

 Topo modifier time: 0.166229 s
 Bisections :: Total: 0, Surface: 0
 Collapses  :: Total: 0, Surface: 0
 Swaps      :: Total: 430, Surface: 3
 Mapping time: 0.037745 s
 Reordering time: 0.038874 s
 ~~~ No flux correction ~~~ 

 ~~~ Mesh Quality Statistics ~~~ 
 Min: 0.5669694553
 Max: 0.999440912
 Mean: 0.8671070099
 Cells: 40523
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 

    Point usage OK.
    Upper triangular ordering OK.
    Topological cell zip-up check OK.
    Face vertices OK.
    Face-face connectivity OK.
    Mesh topology OK.
    Boundary openness (5.813326312e-16 -2.317997225e-19 -4.530630939e-19) Threshold = 1e-06 OK.
    Max cell openness = 2.179222994e-16 OK.
    Max aspect ratio = 4.19270934 OK.
    Minumum face area = 7.109358104e-08. Maximum face area = 1.695177569e-06.  Face area magnitudes OK.
    Min volume = 1.202657362e-11. Max volume = 6.654840401e-10.  Total volume = 4.185231801e-06.  Cell volumes OK.
    Mesh non-orthogonality Max: 51.15319832 average: 16.46141962 Threshold = 70
    Non-orthogonality check OK.
    Face pyramids OK.
    Max skewness = 0.6017764185 OK.
    Mesh geometry OK.
Mesh OK.
after mesh update  
 * T gas min/max   = 300, 773

GAMG:  Solving for T, Initial residual = 1, Final residual = 2.009590784e-09, No Iterations 6
after compute laplacian  
 * T gas min/max   = 277.230632, 773
As you can see, after the mesh update,the temperature is within the initial range [300-700]. After the laplacian, the minimal temperature is under the 300 K.


Best regards

Giancarlo
Giancarlo_IngChimico is offline   Reply With Quote

Old   February 9, 2015, 14:40
Default
  #63
Senior Member
 
Sandeep Menon
Join Date: Mar 2009
Location: Amherst, MA
Posts: 396
Rep Power: 17
deepsterblue will become famous soon enough
This then suggests that you have problems in your solution set up. You should check your schemes and boundary conditions. Since you're solving a laplacian, do you have fixedValue boundary conditions? You might have a saddle-point problem otherwise.
__________________
Sandeep Menon
University of Massachusetts Amherst
https://github.com/smenon
deepsterblue is online now   Reply With Quote

Old   February 9, 2015, 15:00
Post
  #64
New Member
 
Giancarlo
Join Date: Apr 2013
Location: Milan
Posts: 21
Rep Power: 6
Giancarlo_IngChimico is on a distinguished road
Yes, I have fixedValue BC for temperature field:
Code:
dimensions      [0 0 0 1 0 0 0];

internalField   uniform 300;

boundaryField
{
    
    outlet
    {
        type            fixedValue;
        value           uniform 773;
    }

}
Moreover, I have this fvSchemes:
Code:
ddtSchemes
{
    default         Euler;
}

gradSchemes
{
    default         cellLimited Gauss linear 1.0;
    grad(T)         cellLimited Gauss linear 1.0;
}

divSchemes
{
    default         Gauss skewCorrected linear;
}

laplacianSchemes
{
    default         Gauss linear corrected;
    laplacian(DT,T) Gauss linear corrected; 
}

interpolationSchemes
{
   
}

snGradSchemes
{
    default        limited 0.5;
}

fluxRequired
{
    default         no;
    T               ;
}
Do you have any suggestions about these schemes?
Giancarlo_IngChimico is offline   Reply With Quote

Old   February 16, 2015, 13:40
Post
  #65
New Member
 
Giancarlo
Join Date: Apr 2013
Location: Milan
Posts: 21
Rep Power: 6
Giancarlo_IngChimico is on a distinguished road
Hello Sandeep,
I worked about the problem that I explained you last week, but I think that it's not a problem of the discretization schemes.
I have made a very simple case in order to better explain the discrepancy during the solution of the laplacian equation.
My mesh is a box of 16 cells. I move only a face of the box in order to have the restriction of the initial volume. I set the temperature of the domain to 700 (boundary and internal field). Moreover, I compute the temperature laplacian:
Code:
fvm::ddt(T) - fvm::laplacian(DT, T)
Since, I set an initial temperature that it's uniform in the domain, after the laplacian I expect that the temperature should remain constant.
If, I don't move the mesh the temperature is always constant to 700. The solver is able to properly solve the laplacian.
On the other hand, if I set the mesh motion, I register no feasible temperature field. (the solution is not bounded to 700).

I post the results, after the first iteration:
Code:
Time = 0.01
First Time = 0.01
before mesh update  
 * T gas min/max   = 700, 700


************** QualityAssessor(free only) Summary **************

  Evaluating quality for 16 elements.
  This mesh had 16 tetrahedron elements.
  There were no inverted elements detected. 
  No entities had undefined values for any computed metric.

     Element Quality Statistics

     minimum     average         rms     maximum    std.dev.
     2.31432      3.9077     4.06364     5.36664     1.11494

     Number of statistics = 16
     Metric = Inverse Mean Ratio
     Element Quality not based on sample points.


************** QualityAssessor(free only) Summary **************

  Evaluating quality for 16 elements.
  This mesh had 16 tetrahedron elements.
  There were no inverted elements detected. 
  No entities had undefined values for any computed metric.

     Element Quality Statistics

     minimum     average         rms     maximum    std.dev.
     2.32711     3.90594     4.06299     5.37956     1.11869

     Number of statistics = 16
     Metric = Inverse Mean Ratio
     Element Quality not based on sample points.


 ~~~ Mesh Quality Statistics ~~~ 
 Min: 0.18607
 Max: 0.430672
 Mean: 0.280001
 Cells: 16
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 

 Topo modifier time: 0.000501 s
 Bisections :: Total: 0, Surface: 0
 Collapses  :: Total: 0, Surface: 0
 Swaps      :: Total: 4, Surface: 4
 Mapping time: 0.000575 s
 Reordering time: 9.8e-05 s

 ~~~ Mesh Quality Statistics ~~~ 
 Min: 0.18607
 Max: 0.430672
 Mean: 0.280001
 Cells: 16
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 

    Point usage OK.
    Upper triangular ordering OK.
    Topological cell zip-up check OK.
    Face vertices OK.
    Face-face connectivity OK.
    Mesh topology OK.
    Boundary openness (0 0 0) OK.
    Max cell openness = 1.00066e-16 OK.
    Max aspect ratio = 20.6157 OK.
    Minimum face area = 1.40167e-06. Maximum face area = 2.49375e-05.  Face area magnitudes OK.
    Min volume = 1.05712e-09. Max volume = 4.43364e-09.  Total volume = 4.9875e-08.  Cell volumes OK.
    Mesh non-orthogonality Max: 80.9498 average: 62.9846
   *Number of severely non-orthogonal (> 70 degrees) faces: 8.
    Non-orthogonality check OK.
    Face pyramids OK.
    Max skewness = 0.467541 OK.
    Mesh geometry OK.
Mesh OK.
after mesh update  
 * T gas min/max   = 700, 700

DICPCG:  Solving for T, Initial residual = 1, Final residual = 7.56663e-07, No Iterations 6
after solution  
 * T gas min/max   = 698.49, 704.226
I dont't think it's a problem of the discretization scheme, because if I don't move the mesh, the solution is correct.
Now, I'm working with OF-2.3, but I try to solve the same system with (OF-1.6-ext and OF-3.1-ext) and I have always the same problem.
I think that, maybe, not all the mesh fields are updated with the mesh motion.
Do you have any suggestion? I attach the test case and solver.

Thanks in advance

Best regards

Giancarlo
Attached Files
File Type: gz moveDynamicMesh.tar.gz (89.0 KB, 17 views)
File Type: gz TestCase.tar.gz (7.8 KB, 18 views)
Giancarlo_IngChimico is offline   Reply With Quote

Old   March 11, 2015, 09:23
Default
  #66
Member
 
Alexander Bartel
Join Date: Feb 2015
Location: Germany
Posts: 97
Rep Power: 5
alexB is on a distinguished road
Hello Sandeep,

I am interested in using dynamicTopoFVmesh, but can't pull it from github for OF2.3.0 .
Perhaps it is on purpose because of some updates of the files or something like that.
In that case don't mind this post.

If i try to pull dynamicTopoFVmesh for OF2.3.x I get the Version for OF-ext instead. By clicking the link for OF2.3.x a pretty cool Tatooine error 404 shows. (for everybody who has 2 Seconds time here is the link https://github.com/smenon/dynamicTop...new/Port-2.3.x )

kind regards
Alex
alexB is offline   Reply With Quote

Old   March 11, 2015, 09:48
Default
  #67
Senior Member
 
Sandeep Menon
Join Date: Mar 2009
Location: Amherst, MA
Posts: 396
Rep Power: 17
deepsterblue will become famous soon enough
You need to do this to switch to the Port-2.3.x branch after a git clone:

Code:
git checkout Port-2.3.x
This will switch from the 'master' branch to the 'Port-2.3.x' branch
__________________
Sandeep Menon
University of Massachusetts Amherst
https://github.com/smenon
deepsterblue is online now   Reply With Quote

Old   March 11, 2015, 10:03
Default
  #68
Member
 
Alexander Bartel
Join Date: Feb 2015
Location: Germany
Posts: 97
Rep Power: 5
alexB is on a distinguished road
Thanks for the fast reply.

With your hint I tried the clone command with following option.

Quote:
git clone -b Port-2.3.x https://github.com/smenon/dynamicTopoFvMesh/ /home/user/dynamicTopoFVmesh/
Now i have the right files and try on with yout tool.

kind regards
Alex
alexB is offline   Reply With Quote

Old   March 12, 2015, 07:33
Default
  #69
Member
 
Join Date: Jun 2011
Posts: 80
Rep Power: 8
maalan is on a distinguished road
Quote:
t appears that the oscillatingDisplacement patchField provides an absolute value of displacement (from the mean), while the applyFixedValuePatches() function in mesquiteMotionSolver expects an incremental displacement vector for each time-step.

You see the acceleration because the displacement is continuously updated as:

refPoints_ += dPointField; in mesquiteMotionSolver.C

You could write a new boundary condition similar to oscillatingDisplacement which provides displacement increments, or alternatively, I also provide a timeVaryingDisplacement patchField in the repository that uses an interpolation table from file, which might be easier. I would have to look into a fix for the absolute vs. incremental confusion.

Can you try changing the "+=" operator in applyFixedValuePatches to simply "=" and see if that makes a difference?
Hi Sandeep! Did you manage this issue? I am using your tool with 2 cylinders moving harmonically but unfortunately they don't stop and go back, just go forward... Hope you could help.

Best regards,
Antonio
maalan is offline   Reply With Quote

Old   April 13, 2015, 09:29
Default
  #70
Senior Member
 
Sandeep Menon
Join Date: Mar 2009
Location: Amherst, MA
Posts: 396
Rep Power: 17
deepsterblue will become famous soon enough
Hello Antonio,

Could you use this option in mesquiteMotionSolver (under mesquiteOptions in constant/dynamicMeshDict):

Code:
usePointDisplacement    yes;
and specify your boundary conditions using the pointDisplacement file?
__________________
Sandeep Menon
University of Massachusetts Amherst
https://github.com/smenon
deepsterblue is online now   Reply With Quote

Old   June 12, 2015, 04:33
Default
  #71
New Member
 
Matthias Neben
Join Date: Oct 2011
Location: Cottbus (Germany)
Posts: 28
Rep Power: 8
mneben is on a distinguished road
Quote:
Originally Posted by deepsterblue View Post
Ah... I know what the problem is:

It appears that the oscillatingDisplacement patchField provides an absolute value of displacement (from the mean), while the applyFixedValuePatches() function in mesquiteMotionSolver expects an incremental displacement vector for each time-step.

You see the acceleration because the displacement is continuously updated as:

refPoints_ += dPointField; in mesquiteMotionSolver.C

You could write a new boundary condition similar to oscillatingDisplacement which provides displacement increments, or alternatively, I also provide a timeVaryingDisplacement patchField in the repository that uses an interpolation table from file, which might be easier. I would have to look into a fix for the absolute vs. incremental confusion.

Can you try changing the "+=" operator in applyFixedValuePatches to simply "=" and see if that makes a difference?

Hello Sandeep,

actually I'm playing around with different mesh motion methods in OpenFOAM. Therefore I've created a simple test case, which is a carman flow around a moving cylinder (see attachment)
At first I've run moveDynamicMesh without boundary motion to optimize the mesh (as you recommended), afterwards I enabled the boundary motion and run the simulation with pimpleDyMFoam (adjustTimeStep enabled).
Regarding to your post this will fail due to the adjustable time step and the way you've implemented the mesh motion. Thats why I changed
"refPoints_ += dPointField" to "refPoints_ = dPointField". But with both versions of the dynamicTopoFvMesh library (of31 and your git version) I get a floating point exception. Is there any other way to fix this except the timeVaryingDisplacement patchField? How can I achieve the full range of available patchFields?

Best regards
Matthias
Attached Files
File Type: zip kEps_OF31.zip (14.3 KB, 7 views)
mneben is offline   Reply With Quote

Old   February 4, 2016, 13:32
Post
  #72
New Member
 
Giancarlo
Join Date: Apr 2013
Location: Milan
Posts: 21
Rep Power: 6
Giancarlo_IngChimico is on a distinguished road
Dear all,
I'm a Ph.D. student of chemical Enginnering. The aim of my work is to develop a solver within the OpenFOAM framework for the combustion of spherical/cylindrical particle of biomass. To reach this object I have to introduce a moving mesh in order to allow the shrinking of the particle. I'm currently working with the dynamicTopoFvMesh library developed by Sandeep Menon and it works very good for a sphere, but I have several problems for the cylinder.
For sake of clarity, I attach you the picture of my mesh at time 0. I have three boundary patch (inlet, outlet, lateralSurface) and I need to move, at the same time, all the point of each boundary with a prefix velocity along the face normal direction.
As you can see from the second picture that I've attached, the mesh does not evolve with a uniform shrinking in both directions (axial and radial), but the border points, that belong at the same time to two different patches, seem to move with different velocity.
My question is, Is it possible to perform this kind of mesh shrinking with this library?
I attach you my case, I use moveDynamicMesh as solver.

Thanks in advance

Giancarlo

time0.jpg
time2.jpg

cylinder.zip
Giancarlo_IngChimico is offline   Reply With Quote

Old   February 6, 2016, 06:54
Default
  #73
Super Moderator
 
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 10,125
Blog Entries: 39
Rep Power: 110
wyldckat is a glorious beacon of lightwyldckat is a glorious beacon of lightwyldckat is a glorious beacon of lightwyldckat is a glorious beacon of lightwyldckat is a glorious beacon of lightwyldckat is a glorious beacon of light
Quick answer @Giancarlo_IngChimico: I haven't done the math nor tested the case yet, but I'm guessing that the problem is that the sides must be defined to move at 50% the speed of the cylinder.
I suggest that you do a test in ParaView and use the Transform filter to scale down to 0.5 on all directions and then check what were the distance changes that occurred on each surface.

By the way, which OpenFOAM version are you using?
__________________
wyldckat is offline   Reply With Quote

Old   February 6, 2016, 10:07
Default
  #74
New Member
 
Giancarlo
Join Date: Apr 2013
Location: Milan
Posts: 21
Rep Power: 6
Giancarlo_IngChimico is on a distinguished road
Dear Bruno,
Currently I'm using openFoam 2.3.x. Thanks for your help. In my opinion the border points are update twice depending the patch order in the fixedValuePatches subDict. It leads, for some reason, a no uniform mesh motion in both radial and axial coordinates.

Quote:
Originally Posted by wyldckat View Post
Quick answer @Giancarlo_IngChimico: I haven't done the math nor tested the case yet, but I'm guessing that the problem is that the sides must be defined to move at 50% the speed of the cylinder.
I suggest that you do a test in ParaView and use the Transform filter to scale down to 0.5 on all directions and then check what were the distance changes that occurred on each surface.

By the way, which OpenFOAM version are you using?
Giancarlo_IngChimico is offline   Reply With Quote

Old   February 7, 2016, 17:26
Default
  #75
Super Moderator
 
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 10,125
Blog Entries: 39
Rep Power: 110
wyldckat is a glorious beacon of lightwyldckat is a glorious beacon of lightwyldckat is a glorious beacon of lightwyldckat is a glorious beacon of lightwyldckat is a glorious beacon of lightwyldckat is a glorious beacon of light
Hi Giancarlo,

I've tried to run your case with the following software stack:
  • OpenFOAM 2.3.x
  • dynamicTopoFvMesh's branch "Port-2.3.x"
  • Mesquite 2.1.2 build from foam-extend 3.2
  • swak4Foam 0.3.2
And I see what you mean. When I overlay the scale down of the original surface with 0.92, the edges only moved for the curved surface, as shown in the attached image.

The first suspect is the "toPoints" function: http://openfoamwiki.net/index.php/Co...s_are_defined:
Quote:
toPoint
Takes a scalar (or vector) field defined on the faces and interpolates it to the points
A quick search for "toPoints" and I found this:
Quote:
Originally Posted by gschaider View Post
a) to construct a pointVectorField it must be "vector(toPoint(0),toPoint(0.05*(sin(pi*time()))), toPoint(0))"
I've done some considerable trial-and-error testing and it seems that you will need to do specific mathematics for the corner points, because the point mesh field is being overridden by the final boundary condition that is done on "lateralSurface".
This can easily occur, because OpenFOAM's main calculations are done on the faces and cells. And since these points on the edges are common to 2 boundaries and not only one, it currently has no other way to assign dedicated boundary conditions for a group of points.
Therefore, you will need to do specific calculations for the points on the edges of the cylinder... although I haven't really thought about how that can be done with GroovyBC

A quick thinking about it leads me to believe that you can use "inline-if" conditions for defining how calculations are done based on specific conditions. And those conditions you can calculate only for the final boundary.
Hopefully you can draw ideas from here: https://openfoamwiki.net/index.php/C...Usage_Examples

The other possibility would be to rely on pointSets to manipulate specific point groups and assign dedicated point conditions to them.

Best regards,
Bruno
Attached Images
File Type: jpg overlay.jpg (95.4 KB, 20 views)
__________________
wyldckat is offline   Reply With Quote

Old   February 9, 2016, 15:31
Default
  #76
New Member
 
Giancarlo
Join Date: Apr 2013
Location: Milan
Posts: 21
Rep Power: 6
Giancarlo_IngChimico is on a distinguished road
Dear Bruno,
thanks again for your help.
Today I've fixed my problem. dPointField defined in the file mesquiteMotionSolver.C is a pointField where all points displacement are stored. This field doesn't take into account multiple displacement of border points but is being overridden by the final boundary condition that, in my case, is done on "lateralSurface" patch. Adding multiple movements (radial and axial) of the border points in the dPointField , I've fixed my problem.
Currently I can mange shrinking of my cylinder both in radial and axial directions.
Nevertheless, I have another problem with the surface smoothing.
Fist of all, I tried the mesh motion specifying only the outlet and inlet patches in the slipPatches subDict, as follow.
HTML Code:
slipPatches
    {
	outlet;	
	inlet;
    }
As you can see, in the first picture, the mesh motion in both directions is ensured until crush due to lower mesh quality.

In the second test, I perform the mesh motion with the following slipPatches subDict
HTML Code:
slipPatches
    {
	lateralSurface;	
    }
Again, I'm able to perform the mesh motion, until solver crush (always due to lower mesh quality)as explained in the picture 2.

At the end, I added all my patches in the slipPatches subDict
HTML Code:
slipPatches
    {
     inlet;
     outlet
     lateralSurface;	
    }
The result is a complete no sense distortion of my mesh, as highlighted in figure 3.

In other words, it seems the dynamicTopoFvMesh has a bug in multiple patches smoothing.
Do you have any idea about these strange behavior?

Thanks again

Giancarlo

one.jpg
two.jpg
three.jpg
Giancarlo_IngChimico is offline   Reply With Quote

Old   March 28, 2016, 11:43
Default
  #77
Super Moderator
 
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 10,125
Blog Entries: 39
Rep Power: 110
wyldckat is a glorious beacon of lightwyldckat is a glorious beacon of lightwyldckat is a glorious beacon of lightwyldckat is a glorious beacon of lightwyldckat is a glorious beacon of lightwyldckat is a glorious beacon of light
Hi Giancarlo,

Sorry for the late reply, but only today did I finally manage to take a better look into your question.

If my memory doesn't fail me, the "slip patches" feature is for defining the patches that allow the mesh to slide along those patches.
For example, attached are two images from OpenFOAM's tutorial case "mesh/moveDynamicMesh/SnakeRiverCanyon", where:
  1. "snakeRiverCanyon_0.png" shows the initial mesh position, looking at it from one of the sides.
  2. "snakeRiverCanyon_5.png" shows the final position.
The boundary conditions defined in "0/pointDisplacement" are as follows:
  1. The top patch is set to a fixed value, i.e. it doesn't move.
  2. The bottom patch is the one that moves and is using the boundary condition "surfaceDisplacement".
  3. All of the remaining 4 patches on the sides are using the boundary condition "fixedNormalSlip".
As you can see from the 2 images, these 4 lateral patches are the "slip patches", which in this case, they do not change the position along the normal direction to they own surface, but the mesh points on those patches can move along the other 2 directions. This is why they are "slipping".

This was possible in this case, because these 4 patches have strict normal definitions that allow the calculations to be performed properly. But in your case, dynamicTopoFvMesh is trying to deduce the normal directions automatically, but since all directions are changing simultaneously, it's not able to know for certain which side is up, because everything is changing.

I don't know if you've figured out how to solve these issues, but I believe that the trick is to use a boundary condition that uses the original position as a reference for all other iterations. But this will likely require coding said boundary condition.

Best regards,
Bruno
Attached Images
File Type: jpg snakeRiverCanyon_0.jpg (87.8 KB, 21 views)
File Type: jpg snakeRiverCanyon_5.jpg (106.8 KB, 31 views)
wyldckat is offline   Reply With Quote

Old   May 13, 2016, 04:13
Default
  #78
New Member
 
Arne Eggers
Join Date: Oct 2013
Posts: 14
Rep Power: 6
Arne87 is on a distinguished road
Hi all,

I am trying to use dynamicTopoFvMesh to refine a mesh (tets) around a surface in a VOF method with or without the mesquite smoother.
Does anybody have a testcase where this is done in a small scale application? At the moment I am trying figure out what the correct settings in the dynamicMeshDict are. However, I am not experinced with the tool and I dont have a runing test case and the default setting seem not to work. Therefore, it is a lot of try and error.

If anybody has experince with the field refinement tools of dynamicTopoFvMesh and or a testcase. I would be glad about some input.

Best

Arne
Arne87 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
Questions about modeling of a reservoir hwangpo CFX 7 October 30, 2012 22:46
possible interview questions atturh Main CFD Forum 1 February 21, 2012 09:53
Interview Questions Carna FLUENT 0 December 26, 2011 05:35
NACA0012 Validation Case Questions ozzythewise Main CFD Forum 3 August 3, 2010 14:39
Questions about CFD Lebeau alexandre Main CFD Forum 1 April 6, 1999 14:23


All times are GMT -4. The time now is 09:49.