CFD Online Logo CFD Online URL
www.cfd-online.com
[Sponsors]
Home > Forums > Software User Forums > OpenFOAM > OpenFOAM Pre-Processing

cyclicAMI boundary conditions

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

Reply
 
LinkBack Thread Tools Search this Thread Display Modes
Old   April 11, 2019, 06:53
Default cyclicAMI boundary conditions
  #1
Member
 
Adam
Join Date: Nov 2018
Posts: 36
Rep Power: 8
Adam_K is on a distinguished road
I'm using OpenFOAM 5 with blueCFD to simulate the temperature response of a material initially at 300K subjected to left and right sides at 310 K when t>0s. I would like the geometry to translate infinitely in the vertical direction, so I am using cyclicAMI boundary conditions. This is an initial case that I would like to eventually extend towards more complicated ones.

I think that there is a problem with the way I've used cyclicAMI boundary conditions. In using probes to follow the temperature at the top and bottom of the simulation domain, I'm seeing differences that I didn't expect as I thought the surfaces were linked.

This is my geometry, if need be my full casefile and mesh are on DropBox.



In the changeDictionaryDict file, I've described the relationship between the top and bottom patches.

Code:
  
    matrixTop
    {
        type            cyclicAMI;
        neighbourPatch  matrixBottom;
        transform       translational;
        separationVector (0 -0.0002 0);
        matchTolerance  0.0001;
    }
    matrixBottom
    {
        type            cyclicAMI;
        neighbourPatch  matrixTop;
        transform       translational;
        separationVector (0 0.0002 0);
        matchTolerance  0.0001;
    }
The simulation works, and if I look at the central probe, it follows the analytical solution.

Here is a plot of the temperature difference between the probe located at a given y-position and the probe at the bottom (y = 0). I'm not surprised that there is some difference between the probes in the interior, but I expected the top and bottom probes to match much more closely. At the centre (x = 100 µm) they are very close, but at X = 50 µm, there is a considerable difference between the top and bottom of the domain, up to 0.3 K.


Have I messed up my treatment of the cyclicAMI? Or am I missing something here?

Thanks in advance!
Adam
Adam_K is offline   Reply With Quote

Old   July 1, 2019, 04:39
Default
  #2
New Member
 
shach
Join Date: Apr 2019
Posts: 26
Rep Power: 7
shach934 is on a distinguished road
Hi
Have you found a solution to your problem? Is the cyclicAMI interface ok with heat transfer or it needs special setting?
Thanks!
shach934 is offline   Reply With Quote

Old   July 1, 2019, 06:29
Default
  #3
Member
 
Adam
Join Date: Nov 2018
Posts: 36
Rep Power: 8
Adam_K is on a distinguished road
Quote:
Originally Posted by shach934 View Post
Hi
Have you found a solution to your problem? Is the cyclicAMI interface ok with heat transfer or it needs special setting?
Thanks!
No, I never really found an explanation for this.
Adam_K is offline   Reply With Quote

Old   July 1, 2019, 07:44
Default
  #4
New Member
 
shach
Join Date: Apr 2019
Posts: 26
Rep Power: 7
shach934 is on a distinguished road
Ok....Then at last are you still using cyclicAMI and how do you treate it?
shach934 is offline   Reply With Quote

Old   July 2, 2019, 13:53
Default
  #5
Member
 
Yousef
Join Date: Feb 2015
Posts: 40
Rep Power: 11
ykanani is on a distinguished road
Quote:
Originally Posted by Adam_K View Post
I'm using OpenFOAM 5 with blueCFD to simulate the temperature response of a material initially at 300K subjected to left and right sides at 310 K when t>0s. I would like the geometry to translate infinitely in the vertical direction, so I am using cyclicAMI boundary conditions. This is an initial case that I would like to eventually extend towards more complicated ones.

I think that there is a problem with the way I've used cyclicAMI boundary conditions. In using probes to follow the temperature at the top and bottom of the simulation domain, I'm seeing differences that I didn't expect as I thought the surfaces were linked.

This is my geometry, if need be my full casefile and mesh are on DropBox.



In the changeDictionaryDict file, I've described the relationship between the top and bottom patches.

Code:
  
    matrixTop
    {
        type            cyclicAMI;
        neighbourPatch  matrixBottom;
        transform       translational;
        separationVector (0 -0.0002 0);
        matchTolerance  0.0001;
    }
    matrixBottom
    {
        type            cyclicAMI;
        neighbourPatch  matrixTop;
        transform       translational;
        separationVector (0 0.0002 0);
        matchTolerance  0.0001;
    }
The simulation works, and if I look at the central probe, it follows the analytical solution.

Here is a plot of the temperature difference between the probe located at a given y-position and the probe at the bottom (y = 0). I'm not surprised that there is some difference between the probes in the interior, but I expected the top and bottom probes to match much more closely. At the centre (x = 100 µm) they are very close, but at X = 50 µm, there is a considerable difference between the top and bottom of the domain, up to 0.3 K.


Have I messed up my treatment of the cyclicAMI? Or am I missing something here?

Thanks in advance!
Adam
I am not sure how the BlueCFD works in regards to the probing the data, However, for the cyclic patches you should expect the patch values exactly math and not the cell center values near the patch. Please note that, the patch values for cyclic cases are not written in saved data files. Paraview, for example, assumes zerogradient if the patch values does not exist (e.g. cyclic). I suspect that the way that data is probed is causing this mismatch rather than a problem in CyclicAMI itself.
You may need to directly probe the boundary values using boundaryCloud (see OpenFOAM-5.x/etc/caseDicts/postProcessing/probes/). Otherwise, I believe it uses the cell center data in someway to return the value.

Hope this helps,
Regards
ykanani is offline   Reply With Quote

Old   July 3, 2019, 01:54
Default
  #6
Member
 
Adam
Join Date: Nov 2018
Posts: 36
Rep Power: 8
Adam_K is on a distinguished road
Quote:
Originally Posted by ykanani View Post
I am not sure how the BlueCFD works in regards to the probing the data, However, for the cyclic patches you should expect the patch values exactly math and not the cell center values near the patch. Please note that, the patch values for cyclic cases are not written in saved data files. Paraview, for example, assumes zerogradient if the patch values does not exist (e.g. cyclic). I suspect that the way that data is probed is causing this mismatch rather than a problem in CyclicAMI itself.
You may need to directly probe the boundary values using boundaryCloud (see OpenFOAM-5.x/etc/caseDicts/postProcessing/probes/). Otherwise, I believe it uses the cell center data in someway to return the value.

Hope this helps,
Regards
This makes sense and is along the lines with what I was thinking (but not super confident about).

In the end, the actual probe values at those points isn't very important to me and I've realized that using cyclicAMI vs zeroGradient BCs doesn't impact my final simulation results (temperature profile at the center of the slab).
Adam_K is offline   Reply With Quote

Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
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 Off
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
sliding mesh problem in CFX Saima CFX 46 September 11, 2021 08:38
CGNS Boundary conditions using SU2 denzell SU2 3 July 9, 2018 06:58
Basic Nozzle-Expander Design karmavatar CFX 20 March 20, 2016 09:44
Low torque values on Screw Turbine Shaun Waters CFX 34 July 23, 2015 09:16
Question about heat transfer coefficient setting for CFX Anna Tian CFX 1 June 16, 2013 07:28


All times are GMT -4. The time now is 17:56.