[Nek5000-users] par file and moving mesh
nek5000-users at lists.mcs.anl.gov
nek5000-users at lists.mcs.anl.gov
Fri Oct 27 08:11:14 CDT 2017
One more update on this matter. I generated a mesh with cubit that I exported in a exodus format and in a msh format. I then did the following:
- in the first case, I used the exo2nek script to generate the re2 file, and run Nek5000 to get a rea file by calling ‘gen_rea’.
- I used the msh2nek python script to generate a rea file.
My geometry has a moving boundary conditions and the mesh motion is solved by Nek5000 in my current setting.
I observe the following when running all above rea files with the same Nek5000 compiled usr file:
- when running the Nek5000 session with the re2 file generated from the exo2nek script, the mesh is static when visualized with Visit. The log file shows that Nek5000 is solving for the mesh motion, though.
- when running the Nek5000 session with the rea file generated with the gen_rea call, the mesh moves when visualized with Visit, but Nek5000 exits the run and writes a file named ‘xyz***’.
- when running the Nek5000 session with the rea file generated with the python script, the mesh moves, the solution looks good and Nek5000 runs all the way to the final time specified in the rea file.
When running the Nek5000 session with the re2 file generated with the exo2nek script, I set the boundary condition in the usrdat subroutine. At first glance, it seems to be the right approach since the boundary conditions are correctly labeled in the rea file that is generated with gen_rea. But because Nek5000 exits with an error message when I run the rea file coming from the gen_rea call, I am not so sure. Should I be setting the boundary conditions at a different initialization stage?
Note that I used the exo2nek script for other geometries that have more common boundary conditions (v and O), and I did not run into any issue. This problem seems to be specific to the moving mesh and boundary conditions capabilities, I think.
Once again, I would appreciate any help on this matter.
Thanks,
Marco
On Oct 24, 2017, at 12:55 PM, Delchini, Marc-Olivier G. <delchinimg at ornl.gov<mailto:delchinimg at ornl.gov>> wrote:
I specify the boundary conditions in the usr file using the following piece of code:
do i=1,nelt
do j=1,2*ndim
if(bc(5,j,i,1).eq.1) then
cbc(j,i,1)='mv '
elseif(bc(5,j,i,1).eq.2) then
cbc(j,i,1)='W '
elseif(bc(5,j,i,1).eq.3) then
cbc(j,i,1)='W '
elseif(bc(5,j,i,1).eq.4) then
cbc(j,i,1)='W '
else
cbc(j,i,1)='E '
endif
enddo
enddo
Marco
On Oct 24, 2017, at 12:39 PM, nek5000-users at lists.mcs.anl.gov<mailto:nek5000-users at lists.mcs.anl.gov> wrote:
How do you specify the BC in the exo case?
On 24 Oct 2017, at 18:05, "nek5000-users at lists.mcs.anl.gov<mailto:nek5000-users at lists.mcs.anl.gov>" <nek5000-users at lists.mcs.anl.gov<mailto:nek5000-users at lists.mcs.anl.gov>> wrote:
Stefan,
thank for your reply.
My mesh moves if I write the mesh in a rea file. If I use the mesh generated from exo2nek script, the mesh does not move.
Marco
> On Oct 24, 2017, at 11:59 AM, nek5000-users at lists.mcs.anl.gov<mailto:nek5000-users at lists.mcs.anl.gov> wrote:
>
> Marco,
>
> please note that the .par file is still experimental and not as robust as the good old .rea.
> It looks like I forgot to support the viscosity and tolerance for the mesh elasticity solver - so the default values 0.4 and 0.02 will be used. Anyway, your mesh should be moving unless there is something wrong with the BC in the exo case.
>
> Cheers,
> Stefan
>
> -----Original message-----
>> From:nek5000-users at lists.mcs.anl.gov<mailto:nek5000-users at lists.mcs.anl.gov> <nek5000-users at lists.mcs.anl.gov<mailto:nek5000-users at lists.mcs.anl.gov>>
>> Sent: Monday 23rd October 2017 22:15
>> To: nek5000-users at lists.mcs.anl.gov<mailto:nek5000-users at lists.mcs.anl.gov>
>> Subject: Re: [Nek5000-users] par file and moving mesh
>>
>> Hi all,
>>
>> I have an update on this issue.
>>
>> The mesh I am using was generated in Cubit and then converted to the Nek5000 re2 format using the exo2nek script. I call the function ‘gen_rea’ to make Nek5000 write the mesh in a rea file. My mesh has a moving boundary condition, and the mesh motion is computed by the ALE solver. I then do the following:
>> 1) I run my session using the mesh read from the re2 file that comes from the exo2nek script.
>> 2) I run my session using the rea file that was generated by the function call ‘gen_rea'.
>>
>> In the first case, the output file does not show the mesh motion even though the velocity profile seems correct. In the second case, the mesh motion shows in the output file when I visualize the solution with Visit.
>>
>> Is this a bug, or simply a misuse of the exo2nek script?
>>
>> Marco
>>
>>> On Oct 19, 2017, at 8:51 AM, nek5000-users at lists.mcs.anl.gov<mailto:nek5000-users at lists.mcs.anl.gov> <Nek5000-users at lists.mcs.anl.gov<mailto:Nek5000-users at lists.mcs.anl.gov>> wrote:
>>>
>>> Hi all,
>>>
>>> I am trying to switch from a rea file to a par file and I am having difficulties with the moving mesh capabilities. When visualizing the numerical solution, the mesh is not moving, whereas it was moving with a previous version of Nek5000.
>>>
>>> I copied the par file from the my_cyl examples as a start point. The main different between my session and the mv_cyl session is the way the mesh motion is handled. I believe the mesh velocity is provided by the user through a function, whereas in my session the mesh velocity is solved for.
>>>
>>> Below is the par file I am currently using:
>>>
>>> #
>>> # nek parameter file
>>> #
>>> [GENERAL]
>>> #startFrom = restart.fld
>>> stopAt = numSteps
>>> endTime = 0
>>> numSteps = 1000
>>>
>>> dt = 1e-03
>>> timeStepper = bdf #bdf #char #steady
>>> tOrder = 3
>>> variableDt = no
>>> maxCFL = 2.0
>>>
>>> writeControl = timeStep #runTime
>>> writeInterval = 50
>>>
>>> dealiasing = yes
>>> userParam01 = 1.16
>>> userParam02 = 1.8550800E-05
>>>
>>> [PROBLEMTYPE]
>>> lowMachNumber = no
>>> variableProperties = yes
>>> dp0dt = no
>>>
>>> [MESH]
>>> motion = yes
>>> meshVelocity = no
>>>
>>> [PRESSURE]
>>> residualTol = 1e-10
>>> residualProj = no
>>> #preconditioner = amg
>>>
>>> [VELOCITY]
>>> residualTol = 1e-12
>>> residualProj = no
>>>
>>>
>>> Any help will be appreciated.
>>>
>>> Thanks,
>>>
>>> Marco
>>>
>>> _______________________________________________
>>> Nek5000-users mailing list
>>> Nek5000-users at lists.mcs.anl.gov<mailto:Nek5000-users at lists.mcs.anl.gov>
>>> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users
>>>
>>
>> _______________________________________________
>> Nek5000-users mailing list
>> Nek5000-users at lists.mcs.anl.gov<mailto:Nek5000-users at lists.mcs.anl.gov>
>> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users
>>
> _______________________________________________
> Nek5000-users mailing list
> Nek5000-users at lists.mcs.anl.gov<mailto:Nek5000-users at lists.mcs.anl.gov>
> https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users
_______________________________________________
Nek5000-users mailing list
Nek5000-users at lists.mcs.anl.gov<mailto:Nek5000-users at lists.mcs.anl.gov>
https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users
_______________________________________________
Nek5000-users mailing list
Nek5000-users at lists.mcs.anl.gov<mailto:Nek5000-users at lists.mcs.anl.gov>
https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/nek5000-users/attachments/20171027/6ba39d51/attachment-0001.html>
More information about the Nek5000-users
mailing list