I've been running a moving mesh with ASI in which I run one revolution with each run. I've been increasing the pressure under-relaxation with each restart (I restart with the new BC type option even though I'm not changing BC type). For my last run I increased the pressure under-relaxation from 0.5 to 1.0 and I decreased the U,V,W,T residual tolerances for 0.01 to 0.0001. It ran 3/4 of a revolution and then stopped with the following message: **** ERROR #240 **** 1 MASTER FACES AND 1 SLAVE FACES REMAIN UNMATCHED CHECK MOVING GRID COMMANDS, OR CHANGE AREA TOLERANCE FACTOR (RCON 12) CURRENT TOLERANCE FACTOR: 0.200000E-01 CHANGE TO AT LEAST 0.50588

The ASI area mismatch error occurs no matter what solver parameters we use.

Please let me know the possible causes for why we can run 3 revolutions fine, but on the 4th one the error occurs.

It could be the accumulation of round-off error in your vertex coordinates: the longer you run, the greater the error, until eventually a tolerance is exceeded. What you could try is defining the mesh motion in terms of absolute time, rather than adding "deltas" to the vertex coordinates at each time-step. The latter is vulnerable to round-off error.

Hello Richard,

Thanks a lot for your reply. My colleague and me thought of this scenario but we were not sure of it. Your explanation sounds very logical and correct for our case.

But I thought that we wrote the .cgrd file wrt absolute time rather than "deltas". I am sending you my .cgrd file and we here want to know as to whether our .cgrd file is written in abolute time or not. And if not, how to modify this file for absolute time instead of deltas.

! events file to move grid for wave_a

! for coarse wave_a case, vertex at first rotor LE/RMIN is at ILE (= 3)

! with inlet grid included (1092 vert) this vertex is 1095

*SET,VNUM,1095

! fan motion in deg/s

*SET,DPS,10300 * 360 / 60

*IF,TIME,GT,0,THEN

! new angular position

*SET,TANG,TIME * DPS

! current ang position of monitor vertex (why not set csys 2 yet?)

*GET,CPOS,Y,VNUM

! offset angle to move

*SET,TOFF,TANG - CPOS

! collect cells & verts to move

CSET,NEWS,TYPE,21

CSET,ADD,TYPE,29

VSET,NEWS,CSET

! finally set cylindrical (should have done before?) CSYS,2

! move vertex set by TOFF

VGEN,2,0,VSET,,,0,TOFF,0

*ENDIF

Hi Arnab,

This motion definition uses relative time, because you calculate TOFF since the previous time-step and add it to each vertex. Over time, the error in this will accumulate and will be different for each vertex, so the relative position of the vertices will change.

A very simple fix would be to have a .vrt file containing the t=0 vertex positions. You could VREAD this just before you do *GET,CPOS,Y,VNUM and the effect will be that TOFF is the absolute change since t=0. The disadvantage of this is that it is slow to read the .vrt file each time-step. I've heard there's a switch to achieve the same effect, but I don't know what it is.

Hello Richard,

The switch is 79.

SWITCH 79 Y: Alternative mode for STAR-PROSTAR interaction for moving mesh calculation where PROSTAR mesh movement will always be based on the original mesh in the .mdl file.

But when I restart my calculations It crashes after few time steps telling me "Negative Densities found in more than 100 cells". This is a lot different from the errors we used to get when we used previous .cgrd file. During then, the results were coming good and the file was crashing after 4rth or 5th revolution.

Any comments on it?

.cgrd file along with switch 79 turned on.

*SET,DPS, 10300 * 360 / 60

*SET,TANG,TIME * DPS

CSYS,2

CSET,NEWS,TYPE,21

CSET,ADD,TYPE,29

VSET,NEWSET,CSET

VGEN,2,0,VSET,,,0,TANG,0

You can change Rcon in command line.

Hi Kevin,

Isnt it correct that the bigger the RCON value is the higher we loose the accuracy??

Arnab