i have managed to compile the release 1.0.5, ( for ubuntu amd64 ) using NGSolve Rev 214 and Netgen Rev 266,
i few issues on the way, but now, although the examples mostly work, when i adjust the parameters and/or the net, for a problem i am interested in, i often get divergence after a few iterations, ie all the values become NaN.
would there now be a better recommendation for the versions i compile?
also
what are the units for the viscosity and length?
thank you.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
i have ngs-flow compiled, i also compiled netgen and ngsolve so that i could have the indicated tested revisions, but i am getting a lot of segmentation faults and 'libc: double free or corruption' trace backs.
but i am not that concerned because these crashes are quite predictable, so i think with the right setup i can do what i want, but i was hopeful that some newer revisions would be more stable, are there newer combinations of revisions that are tested?
i am particularly interested in the CSG geometry source, because it seems to me that i can easily have a script go thought a series of slight alterations to a design, so it can be optimised for a particular parameter, specifically a pressure difference between two places within the geometry.
i do have a few concerns though:
1. with SI units, the dynamic viscosity, nu (m.m/s), of water is about 1e-6, and air about 1e-5, the "cylinder" model uses 1e-3, something like glyserol, but you never see eddies in this material that the result shows.
2. also in the cylinder model the pressure (p) seems to be reversed? it is lower upstream and higher downstream of the cylinder.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
There is a newer version, yes, the svn-version. But this version also needs the up-to-date NGSolve version. Perhaps some of the segmentation faults disappear there?!
Can you be more specific about the places where the segmentation faults occur? Perhaps we can clean them up then.
To your concerns:
2. You are right, we are using -p instead of p. It was not so important until now, but you are right, we should probably change that.
1. I think everything is ok so for. The geometry has sizes of half a meter! So with glyserol and an inflow velocity of 1.5 m/s and the diameter of 0.1 m, we have - even for glyserol - a Reynolds number of 150.
To your effects with time integration: Until now we have some semi-implicit methods and no adaptive procedure, so the USER has to provide a stable time step. These are issues we are working on.
Good luck with your studies and ngsflow. If other problems occur, feel free to ask more questions
schruste
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
> There is a newer version, yes, the svn-version. But this version also needs the up-to-date NGSolve version. Perhaps some of the segmentation faults disappear there?!
i compiled from specific svn-versions so as to get NGSolve Rev 214 and Netgen Rev 266,as indicated in the help as being most tested for ngflow and because there are three projects so there are a lot of possible combinations, i wondered if you could suggest a good combination of revisions for the three projects.
> 2. You are right, we are using -p instead of p. It was not so important until now, but you are right, we should probably change that.
this is what i had assumed, but its nice to have it confirmed.
> 1. I think everything is ok so for. The geometry has sizes of half a meter! So with glyserol and an inflow velocity of 1.5 m/s and the diameter of 0.1 m, we have - even for glyserol - a Reynolds number of 150.
but shouldn't below Re~2400 be laminar?
also, i think in the cylinder example, the oscillations are pipe scale, they dont die away, so its probably better to use 1m for the size, so Re~1500, but still a bit low.
> To your effects with time integration: Until now we have some semi-implicit methods and no adaptive procedure, so the USER has to provide a stable time step. These are issues we are working on.
I am glad someone is actually interested in ngsflow.
So, the newest versions of ngsflow (rev 126) runs nice with the latest svn revision of NGSolve and Netgen or the releases 4.9.12 of netgen and ngsolve. Netgen is the less critical dependency here. I guess even 4.9.11 for netgen would work…
>but shouldn't below Re~2400 be laminar?
That's correct for pure channel flow without obstacles. The circle triggers the instability. I think for Re=50 really small vortex street can be triggered and for Re around 150 they are stable. Nevertheless as long as the vortex street is regular, the flow is still laminar! I think the simulation is consistent with measurements and other simulations tools.
To smear out the vortex street you have to increase height and the width of the channel.
Nice! I think your Reynoldsnumber is around 36 in this case. If you double it (e.g. double velocity) you should also trigger at leat a small karman vortex street.
If you upgrade to the newest version you will also benefit from some new features:
Time Integration: The second order method seems to be the best choice if you want larger time steps. Another nice thing is that you can adapt the time step via the gui with the new version. So the easiest choice until now to find the stability limit experimentically is to start with a small time step and increase it step by step via gui during the simulation. Once you have the nice time start restart the simulaiton. Of course it is not the best solution for the future, but for now it better than nothing =).
All other "new feature" can be found in the wiki.
Thanks for the feedback so far,
schruste
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
hi
i have managed to compile the release 1.0.5, ( for ubuntu amd64 ) using NGSolve Rev 214 and Netgen Rev 266,
i few issues on the way, but now, although the examples mostly work, when i adjust the parameters and/or the net, for a problem i am interested in, i often get divergence after a few iterations, ie all the values become NaN.
would there now be a better recommendation for the versions i compile?
also
what are the units for the viscosity and length?
thank you.
Hi Simon
after managing to install Netgen and NGSolve it should not be too difficult to install ngs-flow.
If the solution diverges, decrease the time-step, ngs-flow is based on a semi-implicit solver.
all units are SI (or anything else as long as everything matches)
JS
Hi JS, thanks for your reply;
i have ngs-flow compiled, i also compiled netgen and ngsolve so that i could have the indicated tested revisions, but i am getting a lot of segmentation faults and 'libc: double free or corruption' trace backs.
but i am not that concerned because these crashes are quite predictable, so i think with the right setup i can do what i want, but i was hopeful that some newer revisions would be more stable, are there newer combinations of revisions that are tested?
i am particularly interested in the CSG geometry source, because it seems to me that i can easily have a script go thought a series of slight alterations to a design, so it can be optimised for a particular parameter, specifically a pressure difference between two places within the geometry.
i do have a few concerns though:
1. with SI units, the dynamic viscosity, nu (m.m/s), of water is about 1e-6, and air about 1e-5, the "cylinder" model uses 1e-3, something like glyserol, but you never see eddies in this material that the result shows.
2. also in the cylinder model the pressure (p) seems to be reversed? it is lower upstream and higher downstream of the cylinder.
Hi Simon,
There is a newer version, yes, the svn-version. But this version also needs the up-to-date NGSolve version. Perhaps some of the segmentation faults disappear there?!
Can you be more specific about the places where the segmentation faults occur? Perhaps we can clean them up then.
To your concerns:
2. You are right, we are using -p instead of p. It was not so important until now, but you are right, we should probably change that.
1. I think everything is ok so for. The geometry has sizes of half a meter! So with glyserol and an inflow velocity of 1.5 m/s and the diameter of 0.1 m, we have - even for glyserol - a Reynolds number of 150.
To your effects with time integration: Until now we have some semi-implicit methods and no adaptive procedure, so the USER has to provide a stable time step. These are issues we are working on.
Good luck with your studies and ngsflow. If other problems occur, feel free to ask more questions
schruste
Hi schruste,
> There is a newer version, yes, the svn-version. But this version also needs the up-to-date NGSolve version. Perhaps some of the segmentation faults disappear there?!
i compiled from specific svn-versions so as to get NGSolve Rev 214 and Netgen Rev 266,as indicated in the help as being most tested for ngflow and because there are three projects so there are a lot of possible combinations, i wondered if you could suggest a good combination of revisions for the three projects.
> 2. You are right, we are using -p instead of p. It was not so important until now, but you are right, we should probably change that.
this is what i had assumed, but its nice to have it confirmed.
> 1. I think everything is ok so for. The geometry has sizes of half a meter! So with glyserol and an inflow velocity of 1.5 m/s and the diameter of 0.1 m, we have - even for glyserol - a Reynolds number of 150.
but shouldn't below Re~2400 be laminar?
also, i think in the cylinder example, the oscillations are pipe scale, they dont die away, so its probably better to use 1m for the size, so Re~1500, but still a bit low.
> To your effects with time integration: Until now we have some semi-implicit methods and no adaptive procedure, so the USER has to provide a stable time step. These are issues we are working on.
playing with time step has helped a lot, i'm very pleased to have a nice laminar picture, see;http://picasaweb.google.co.uk/lh/photo/gELQ-JAYuZNk9_0m-rO4LA?feat=directlink
> Can you be more specific about the places where the segmentation faults occur? Perhaps we can clean them up then.
if you can suggest the revisions to try, i'll be happy to pass on details of anything i can recreate.
thanks, Simon
Hi Simon,
I am glad someone is actually interested in ngsflow.
So, the newest versions of ngsflow (rev 126) runs nice with the latest svn revision of NGSolve and Netgen or the releases 4.9.12 of netgen and ngsolve. Netgen is the less critical dependency here. I guess even 4.9.11 for netgen would work…
>but shouldn't below Re~2400 be laminar?
That's correct for pure channel flow without obstacles. The circle triggers the instability. I think for Re=50 really small vortex street can be triggered and for Re around 150 they are stable. Nevertheless as long as the vortex street is regular, the flow is still laminar! I think the simulation is consistent with measurements and other simulations tools.
To smear out the vortex street you have to increase height and the width of the channel.
>playing with time step has helped a lot, i'm very pleased to have a nice laminar picture, see;http://picasaweb.google.co.uk/lh/photo/gELQ-JAYuZNk9_0m-rO4LA?feat=directlink
Nice! I think your Reynoldsnumber is around 36 in this case. If you double it (e.g. double velocity) you should also trigger at leat a small karman vortex street.
If you upgrade to the newest version you will also benefit from some new features:
Time Integration: The second order method seems to be the best choice if you want larger time steps. Another nice thing is that you can adapt the time step via the gui with the new version. So the easiest choice until now to find the stability limit experimentically is to start with a small time step and increase it step by step via gui during the simulation. Once you have the nice time start restart the simulaiton. Of course it is not the best solution for the future, but for now it better than nothing =).
All other "new feature" can be found in the wiki.
Thanks for the feedback so far,
schruste
Hi schruste,
i going to start adding new threads for anything that seems like its a separate issue, to break things up a bit.
simon