RFR Solver error

RPFigueiredo · October 22, 2014, 14:16

Hello again!

I know that this is perhaps the most common error message in this forum, but I can't figure it out: I get the floating point overflow error everytime I set a rotating frame of reference.

The meshes are OK, since they work when stationary. The timestep is set to 1/speed, and the interfaces are set to frozen rotor (only the impeller is in a RFR).

There must be something I am missing in the set up. Is someone more experience able to pick something up? I mean, the solver barely starts before signaling the error!

Thanks in advance!

ghorrocks · October 22, 2014, 18:47

Quote:

I know that this is perhaps the most common error message in this forum

Yes, that is right

That is why we wrote this FAQ: http://www.cfd-online.com/Wiki/Ansys...do_about_it.3F

RPFigueiredo · October 22, 2014, 20:08

Yea, but the FAQ does not say a word about why it happens when rotation is involved.

The time step is correct, the mesh has no elements of quality below 0.5, and it still happens.

My question is about the link between numerical stability and the RFR. When I run the thing with a stationary impeller, all is fine.

ghorrocks · October 22, 2014, 20:21

Quote:

The time step is correct

How can you be sure of this when it is not converging? Have you tried a smaller time step as the FAQ suggests? This is the most common fix for this problem.

RPFigueiredo · October 22, 2014, 20:28

1/(10*speed) didn't work. The reason I posted the issue here is because the problem isn't the convergence.

As soon as the solver starts the error appears, before iteration 1. That's what's bugging me. I've even tried a simpler model, just a spinning tube - just because it's rotating, the solver barely starts.

Very unsettling!

JuPa · October 23, 2014, 06:37

Does the job run in serial and not parallel?

ghorrocks · October 23, 2014, 08:11

RFR runs are normally quite reliable. I rarely have troubles with them. RFR does not significantly increase the numerical instabilities in most cases.

If you run a simple model and that does not work either then I suspect you are setting up RFR wrong. Have you done the tutorial examples on RFR? Can you post some details of the simple RFR model you did?

RPFigueiredo · October 23, 2014, 08:45

Yes, I've done tutorials, I've modeled rotor-stator interaction too, and I haven't encoutered this issue.

All the boundaries are walls, except for the top inlet, the anular outlet and the two interfaces, both set to General COnnection/Frozen Rotor with pitch change of 1. I cannot set inlet/outlet as counter rotating (and really that's why I am not modeling only the impeller, but the whole system) - perhaps leave them as openings and check if the rotation works its magic?

And RicochetJ, the job doesn't run in either!

October 22, 2014, 14:16	RFR Solver error	#1
RPFigueiredo Member Rolando Figueiredo Join Date: Mar 2013 Posts: 41 Rep Power: 13	Hello again! I know that this is perhaps the most common error message in this forum, but I can't figure it out: I get the floating point overflow error everytime I set a rotating frame of reference. The meshes are OK, since they work when stationary. The timestep is set to 1/speed, and the interfaces are set to frozen rotor (only the impeller is in a RFR). There must be something I am missing in the set up. Is someone more experience able to pick something up? I mean, the solver barely starts before signaling the error! Thanks in advance!

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Undeclared Identifier Errof UDF	SteveGoat	Fluent UDF and Scheme Programming	7	October 15, 2014 08:11
OpenFOAM without MPI	kokizzu	OpenFOAM Installation	4	May 26, 2014 10:17
Compiling dynamicTopoFvMesh for OpenFOAM 2.1.x	Saxwax	OpenFOAM Installation	25	November 29, 2013 06:34
checking the system setup and Qt version	vivek070176	OpenFOAM Installation	22	June 1, 2010 13:34
POSDAT problem	piotka	STAR-CD	4	June 12, 2009 09:43

October 22, 2014, 20:08		#3
RPFigueiredo Member Rolando Figueiredo Join Date: Mar 2013 Posts: 41 Rep Power: 13	Yea, but the FAQ does not say a word about why it happens when rotation is involved. The time step is correct, the mesh has no elements of quality below 0.5, and it still happens. My question is about the link between numerical stability and the RFR. When I run the thing with a stationary impeller, all is fine.

October 22, 2014, 20:28		#5
RPFigueiredo Member Rolando Figueiredo Join Date: Mar 2013 Posts: 41 Rep Power: 13	1/(10*speed) didn't work. The reason I posted the issue here is because the problem isn't the convergence. As soon as the solver starts the error appears, before iteration 1. That's what's bugging me. I've even tried a simpler model, just a spinning tube - just because it's rotating, the solver barely starts. Very unsettling!

October 23, 2014, 06:37		#6
JuPa Senior Member Mr CFD Join Date: Jun 2012 Location: Britain Posts: 361 Rep Power: 15	Does the job run in serial and not parallel?

October 23, 2014, 08:11		#7
ghorrocks Super Moderator Glenn Horrocks Join Date: Mar 2009 Location: Sydney, Australia Posts: 17,872 Rep Power: 144	RFR runs are normally quite reliable. I rarely have troubles with them. RFR does not significantly increase the numerical instabilities in most cases. If you run a simple model and that does not work either then I suspect you are setting up RFR wrong. Have you done the tutorial examples on RFR? Can you post some details of the simple RFR model you did?

October 23, 2014, 08:45		#8
RPFigueiredo Member Rolando Figueiredo Join Date: Mar 2013 Posts: 41 Rep Power: 13	Yes, I've done tutorials, I've modeled rotor-stator interaction too, and I haven't encoutered this issue. All the boundaries are walls, except for the top inlet, the anular outlet and the two interfaces, both set to General COnnection/Frozen Rotor with pitch change of 1. I cannot set inlet/outlet as counter rotating (and really that's why I am not modeling only the impeller, but the whole system) - perhaps leave them as openings and check if the rotation works its magic? And RicochetJ, the job doesn't run in either!