Re: [Gmsh] Question about Progression and Bump
Hi Alessandro, If I am understanding you correctly, you can already accomplish this yourself as a user by calculating the number of nodes you need to specify for a given progression to get a desired first element size. From a CFD perspective, what would make the most sense intuitively would be to be able to specify the length of the first element and the growth rate / progression and let gmsh calculate the total number of nodes. Of course in an ideal world if you could choose from any of the options for a given geometry would be best, but development time is limited, and these are all algorithmically equivalent to each other and can currently be accomplished with only a few extra lines of code in the .geo file. In terms of actually adding functionality what would be the most useful would be the ability to specify the first element length at both ends of a line segment and the growth rate from each end and have gmsh distribute points along the line segment smoothly to obey these progressions. Currently there is a bit of added work for a user to have to construct 2 line segments to accomplish this and then also have to do some additional algebra to ensure that the grid spacing is relatively smooth where the unconstrained ends of the line segments meet. Thanks, Nathan J. Neeteson, M.Sc. Flow Control Research Engineer RGL Reservoir Management Inc. Engineering & Design Group P. 403.930.0371 (ext. 8371) | C. 613.929.6283 nneete...@rglinc.com<mailto:nneete...@rglinc.com> | rglinc.com API Q1™ and ISO 9001:2015 certified facilities. NOTE: Email and URL addresses have recently changed From: Alessandro Vicini [mailto:alessandro.vic...@sitael.com] Sent: October 25, 2018 3:14 AM To: Ruth Vazquez Sabariego ; Nathan J. Neeteson Cc: gmsh@onelab.info Subject: R: [Gmsh] Question about Progression and Bump It might be useful having the possibility to specify the number of intervals and the length of the first element, rather than the progression… A. Da: gmsh [mailto:gmsh-boun...@ace20.montefiore.ulg.ac.be] Per conto di Ruth Vazquez Sabariego Inviato: mercoledì 24 ottobre 2018 16:28 A: Nathan J. Neeteson Cc: gmsh@onelab.info<mailto:gmsh@onelab.info> Oggetto: Re: [Gmsh] Question about Progression and Bump Dear Nathan, As you have noticed, the Bump does not do a double geometrical progression. The formula used is a bit more complicated, you can see what it actually does in the code (meshGEdge.cpp). A double progression is not (yet?) available. Work around by dividing your second region in two? Regards, Ruth — Prof. Ruth V. Sabariego KU Leuven Dept. Electrical Engineering ESAT/Electa, EnergyVille http://www.esat.kuleuven.be/electa<https://urlsand.esvalabs.com/?u=http%3A%2F%2Fwww.esat.kuleuven.be%2Felecta=69b77ccd=6f8d0521=y=y> http://www.energyville.be<https://urlsand.esvalabs.com/?u=http%3A%2F%2Fwww.energyville.be=69b77ccd=5cdb1935=y=y> Free software: http://gmsh.info<https://urlsand.esvalabs.com/?u=http%3A%2F%2Fgmsh.info=69b77ccd=ec49fb48=y=y> | http://getdp.info<https://urlsand.esvalabs.com/?u=http%3A%2F%2Fgetdp.info=69b77ccd=0e857c64=y=y> | http://onelab.info<https://urlsand.esvalabs.com/?u=http%3A%2F%2Fonelab.info=69b77ccd=e3a8f919=y=y> On 23 Oct 2018, at 22:07, Nathan J. Neeteson mailto:nneete...@rglinc.com>> wrote: Hello, I have a question about using Progression and Bump in neighboring blocks in a block-structured mesh. What I want is for the two blocks to have cells of the same height where they meet. I know the thickness of the first cell from the wall (dx0), the length of each line (L), and the progression I want (r), so when I’m using Progression I can calculate the number of nodes to use as N = log(1+(L*(r-1))/(dx0)) / log(r) – 1. Then I can set the appropriate lines to Transfinite and assign them N Using Progression r and it works as expected. However, in one of my blocks I want to refine towards both the top and bottom, so I need to use the Bump option. The problem is that I have no idea what “r” value to use after Bump (using the same r value as is used for Progression does not give me the results I want) and I also have no idea how to calculate the number of points to use along this line. MY first instinct was to calculate the number of points needed as double the number of points for a single progression with half of the length (two progressions end to end). I think this is right, but when I use r after Bump I get no refinement. What value am I supposed to use for number of points and the rate of growth when using the Bump function so that I get the equivalent of the product of two Progressions end to end? Here is a zoomed in look at where I want the first cells to match heights: The bottom block uses single progression and the upper block you are seeing the lower end of the double progression. Here is my .geo file: -
Re: [Gmsh] Question about Progression and Bump
Hi Ruth,
Thanks for your response. I have indeed worked around the problem by dividing
the domain into 2 planes and doing two separate single progressions. I was
still curious what the response would be because I would like understand how
Bump works even if I can't use it for this purpose.
I will look at the file you recommended I look at.
Thanks,
Nathan
Get Outlook for Android<https://aka.ms/ghei36>
From: Ruth Vazquez Sabariego
Sent: Wednesday, October 24, 2018 8:27:41 AM
To: Nathan J. Neeteson
Cc: gmsh@onelab.info
Subject: Re: [Gmsh] Question about Progression and Bump
Dear Nathan,
As you have noticed, the Bump does not do a double geometrical progression.
The formula used is a bit more complicated, you can see what it actually does
in the code (meshGEdge.cpp).
A double progression is not (yet?) available.
Work around by dividing your second region in two?
Regards,
Ruth
—
Prof. Ruth V. Sabariego
KU Leuven
Dept. Electrical Engineering ESAT/Electa, EnergyVille
http://www.esat.kuleuven.be/electa
http://www.energyville.be
Free software: http://gmsh.info | http://getdp.info | http://onelab.info
On 23 Oct 2018, at 22:07, Nathan J. Neeteson
mailto:nneete...@rglinc.com>> wrote:
Hello,
I have a question about using Progression and Bump in neighboring blocks in a
block-structured mesh. What I want is for the two blocks to have cells of the
same height where they meet. I know the thickness of the first cell from the
wall (dx0), the length of each line (L), and the progression I want (r), so
when I’m using Progression I can calculate the number of nodes to use as N =
log(1+(L*(r-1))/(dx0)) / log(r) – 1. Then I can set the appropriate lines to
Transfinite and assign them N Using Progression r and it works as expected.
However, in one of my blocks I want to refine towards both the top and bottom,
so I need to use the Bump option. The problem is that I have no idea what “r”
value to use after Bump (using the same r value as is used for Progression does
not give me the results I want) and I also have no idea how to calculate the
number of points to use along this line. MY first instinct was to calculate the
number of points needed as double the number of points for a single progression
with half of the length (two progressions end to end). I think this is right,
but when I use r after Bump I get no refinement. What value am I supposed to
use for number of points and the rate of growth when using the Bump function so
that I get the equivalent of the product of two Progressions end to end?
Here is a zoomed in look at where I want the first cells to match heights:
The bottom block uses single progression and the upper block you are seeing the
lower end of the double progression.
Here is my .geo file:
---
// orifice properties
orificeLength = 0.03;
orificeRadius = 0.002;
// pipe properties
pipeRadius = 0.05;
// distance from orifice to inlet
inletDist = 5*pipeRadius;
// distance from orifice to outlet
outletDist = 5*pipeRadius;
// grid size parameters
r = 1.1; // growth parameter
dx0 = 1*10^(-4); // first wall dist for y+=1
upstreamNx = (Log(1 + ((inletDist*(r-1))/(dx0))) / Log(r)) - 1; // number of
elements in x direction upstream
downstreamNx = (Log(1 + ((outletDist*(r-1))/(dx0))) / Log(r)) - 1; // number of
elements in x direction upstream
orificeNx = orificeLength/dx0; // number of elements in x direction inside
orifice
upstreamOrificeNy = orificeRadius/dx0;
upstreamPipeNy = 2*((Log(1 + pipeRadius-orificeRadius)/2)*(r-1))/(dx0))) /
Log(r)) - 1);
// element index
i = 1;
// ~~-~~ POINTS ~~-~~
// order of point definition doesn't matter, just give descriptive names
inletCenterPoint = i;
Point(i) = {-orificeLength-inletDist,0,0,1};
i=i+1;
inletPipeWallPoint = i;
Point(i) = {-orificeLength-inletDist,pipeRadius,0,1};
i=i+1;
inletOrificeWallPoint = i;
Point(i) = {-orificeLength-inletDist,orificeRadius,0,1};
i=i+1;
upOrificeCenterPoint = i;
Point(i) = {-orificeLength,0,0,1};
i=i+1;
upOrificePipeWallPoint = i;
Point(i) = {-orificeLength,pipeRadius,0,1};
i=i+1;
upOrificeOrificeWallPoint = i;
Point(i) = {-orificeLength,orificeRadius,0,1};
i=i+1;
// ~~-~~ LINES ~~-~~
// all lines should be defined going up and/or to the right for consistency
inletOrificeLine = i;
Line(i) = {inletCenterPoint,inletOrificeWallPoint};
i=i+1;
inletPipeLine = i;
Line(i) = {inletOrificeWallPoint,inletPipeWallPoint};
i=i+1;
upstreamPipeWallLine = i;
Line(i) = {inletPipeWallPoint,upOrificePipeWallPoint};
i=i+1;
upstreamCenterLine = i;
Line(i) = {inletCenterPoint,upOrificeCenterPoint};
i=i+1;
upstreamOrificeLine = i;
Line(i) = {inletOrificeWallPoint,upOrificeOrificeWallPoint};
i=i+1;
upstreamOrificePlateLine = i;
Line(i) = {upOrificeOrif
Re: [Gmsh] Question about Progression and Bump
Dear Nathan,
As you have noticed, the Bump does not do a double geometrical progression.
The formula used is a bit more complicated, you can see what it actually does
in the code (meshGEdge.cpp).
A double progression is not (yet?) available.
Work around by dividing your second region in two?
Regards,
Ruth
—
Prof. Ruth V. Sabariego
KU Leuven
Dept. Electrical Engineering ESAT/Electa, EnergyVille
http://www.esat.kuleuven.be/electa
http://www.energyville.be
Free software: http://gmsh.info | http://getdp.info | http://onelab.info
On 23 Oct 2018, at 22:07, Nathan J. Neeteson
mailto:nneete...@rglinc.com>> wrote:
Hello,
I have a question about using Progression and Bump in neighboring blocks in a
block-structured mesh. What I want is for the two blocks to have cells of the
same height where they meet. I know the thickness of the first cell from the
wall (dx0), the length of each line (L), and the progression I want (r), so
when I’m using Progression I can calculate the number of nodes to use as N =
log(1+(L*(r-1))/(dx0)) / log(r) – 1. Then I can set the appropriate lines to
Transfinite and assign them N Using Progression r and it works as expected.
However, in one of my blocks I want to refine towards both the top and bottom,
so I need to use the Bump option. The problem is that I have no idea what “r”
value to use after Bump (using the same r value as is used for Progression does
not give me the results I want) and I also have no idea how to calculate the
number of points to use along this line. MY first instinct was to calculate the
number of points needed as double the number of points for a single progression
with half of the length (two progressions end to end). I think this is right,
but when I use r after Bump I get no refinement. What value am I supposed to
use for number of points and the rate of growth when using the Bump function so
that I get the equivalent of the product of two Progressions end to end?
Here is a zoomed in look at where I want the first cells to match heights:
The bottom block uses single progression and the upper block you are seeing the
lower end of the double progression.
Here is my .geo file:
---
// orifice properties
orificeLength = 0.03;
orificeRadius = 0.002;
// pipe properties
pipeRadius = 0.05;
// distance from orifice to inlet
inletDist = 5*pipeRadius;
// distance from orifice to outlet
outletDist = 5*pipeRadius;
// grid size parameters
r = 1.1; // growth parameter
dx0 = 1*10^(-4); // first wall dist for y+=1
upstreamNx = (Log(1 + ((inletDist*(r-1))/(dx0))) / Log(r)) - 1; // number of
elements in x direction upstream
downstreamNx = (Log(1 + ((outletDist*(r-1))/(dx0))) / Log(r)) - 1; // number of
elements in x direction upstream
orificeNx = orificeLength/dx0; // number of elements in x direction inside
orifice
upstreamOrificeNy = orificeRadius/dx0;
upstreamPipeNy = 2*((Log(1 + pipeRadius-orificeRadius)/2)*(r-1))/(dx0))) /
Log(r)) - 1);
// element index
i = 1;
// ~~-~~ POINTS ~~-~~
// order of point definition doesn't matter, just give descriptive names
inletCenterPoint = i;
Point(i) = {-orificeLength-inletDist,0,0,1};
i=i+1;
inletPipeWallPoint = i;
Point(i) = {-orificeLength-inletDist,pipeRadius,0,1};
i=i+1;
inletOrificeWallPoint = i;
Point(i) = {-orificeLength-inletDist,orificeRadius,0,1};
i=i+1;
upOrificeCenterPoint = i;
Point(i) = {-orificeLength,0,0,1};
i=i+1;
upOrificePipeWallPoint = i;
Point(i) = {-orificeLength,pipeRadius,0,1};
i=i+1;
upOrificeOrificeWallPoint = i;
Point(i) = {-orificeLength,orificeRadius,0,1};
i=i+1;
// ~~-~~ LINES ~~-~~
// all lines should be defined going up and/or to the right for consistency
inletOrificeLine = i;
Line(i) = {inletCenterPoint,inletOrificeWallPoint};
i=i+1;
inletPipeLine = i;
Line(i) = {inletOrificeWallPoint,inletPipeWallPoint};
i=i+1;
upstreamPipeWallLine = i;
Line(i) = {inletPipeWallPoint,upOrificePipeWallPoint};
i=i+1;
upstreamCenterLine = i;
Line(i) = {inletCenterPoint,upOrificeCenterPoint};
i=i+1;
upstreamOrificeLine = i;
Line(i) = {inletOrificeWallPoint,upOrificeOrificeWallPoint};
i=i+1;
upstreamOrificePlateLine = i;
Line(i) = {upOrificeOrificeWallPoint,upOrificePipeWallPoint};
i=i+1;
upstreamOrificeEntryLine = i;
Line(i) = {upOrificeCenterPoint,upOrificeOrificeWallPoint};
i=i+1;
// ~~-~~ LINE LOOPS ~~-~~
// all line loops should be oriented clockwise
upstreamPipeLoop = i;
Line Loop(i) =
{inletPipeLine,upstreamPipeWallLine,-upstreamOrificePlateLine,-upstreamOrificeLine};
i=i+1;
upstreamOrificeLoop = i;
Line Loop(i) =
{inletOrificeLine,upstreamOrificeLine,-upstreamOrificeEntryLine,-upstreamCenterLine};
i=i+1;
// ~~-~~ PLANE SURFACES ~~-~~
upstreamPipePlane = i;
Plane
