PRESSURE_CORRECTION=TRUE, more odd results

[gforney]

Application Version:5.3.1
SVN Revision Number:3779
Compile Date:08, April, 09
Operating System:LINUX

This is a problem similar to issue 440. It doesn't require any action if
you have already decided to abandon the pressure correction feature.

I have been modelling air flow in mine shafts and getting odd results. 

I created simple examples to test the feature. Vent_test_1.fds has pressure
correction implemented. The velocities are 50 times what they should be,
and the flow pattern doesn't make sense. Vent_test_2 has the feature
disabled and velocity and flow patterns make sense.

Regards

Dave

Original issue reported on code.google.com by readsalot7 on 2009-09-03 16:49:05

---

• _Attachment: vent_test_1.fds_
• _Attachment: vent_test_2.fds_

[gforney]

Thanks for the info. Yes, I think that PRESSURE_CORRECTION is causing more trouble 
than its worth. The improvements we made to the pressure solver to enable this 
feature have actually solved most of the problems the feature was originally 
designed to address. I guess we just need to find out if anyone actually NEEDS to 
use this -- that is, that their calcs won't run without it. I'll make this the Issue

and keep it open until we resolve the problem.

Original issue reported on code.google.com by mcgratta on 2009-09-03 17:10:13

[gforney]

Dave,

It seems something has improved drastically between SVN 3779 and now (SVN 4629).  The
flow patterns in the center are different (but I don't see why we should believe the
PC=F result over the PC=T) and the velocity field is certainly not off by 50 times.

I have gone back and forth on the utility of PC.  There are certainly cases in which
it is useful (just ask Tony Bova).  But it is delicate and can cause problems if it
is not used properly.  It is still up to the user to create the proper grid
arrangement.  PC works well if the flow is predominantly normal to the mesh
interface.  It works poorly (because the system is ill-conditioned) if the flow is
predominantly parallel to the mesh interface (I would count the flow along the top
and bottom of your center mesh in this category).  If you understand the scheme, this
should make some intuitive sense: the scheme sets a UNIFORM pressure gradient across
the mesh interface to correct the totality of the volume imbalance.  If the flow is
parallel to the interface, the volume error is likely to be an average of several
small fluctuations going both ways across the interface, yet PC pushes everything in
one direction.

Still, given the results from the latest code, the PC=T case may be closer to the
true solution.  Whenever you do a test like this, you should also do a single mesh
case with OBST used to create your channels to see what the correct solution is.

Cheers,
Randy

Original issue reported on code.google.com by randy.mcdermott on 2009-09-03 21:37:29

---

• _Attachment: vent_test_1_1000.png
  _
• _Attachment: vent_test_2_1000.png
  _

[gforney]

Randy,

this is a very useful comment on the function of PC.
I have another question about this topic:
If I am using check_volume_flow in a multi mesh case and there are no ‘Volume flow

errors’, does this mean that there are no significant differences between the multi

mesh case and a comparable single mesh case?

Boris

Original issue reported on code.google.com by Info@F-Sim.de on 2009-09-04 08:58:20

[gforney]

Good question. One of the improvements Randy made to the pressure solver (with or 
without PC) was to force the normal component of velocity to match at mesh 
interfaces at the predictor and corrector part of the time step. Of course, suitable

adjustments need to be made in the calculation of the divergence to maintain 
consistency from time step to time step. In other words, because of the time 
stepping scheme, it is not easy to simply change the velocity at a given point 
because of the close coupling between the pressure and velocity fields. Anyway, all

that CHECK_VOLUME_FLOW does is check that the normal velocity component is the same

at the interface. We still need to do some more work to see how well a single and 
multiple mesh case match. We're working with Susan Kilian of hhpberlin on this 
verfication exercise.

Original issue reported on code.google.com by mcgratta on 2009-09-04 12:38:08

[gforney]

Boris,

Thanks for the comment.  If this is useful, perhaps I will add it to the guides.

Regarding your question, first, I would be surprised if your errors are really that
small for a multi-mesh case without PC (would you mind posting the case for me to
take a look?).  However, if the volume errors are small enough not to prompt a
warning (see Line 1048 of main.f90), then I would be surprised if the solution
differs significantly from the single mesh case.  But I do not have a proof of this
and it may be problem dependent.

Cheers,
Randy

Original issue reported on code.google.com by randy.mcdermott on 2009-09-04 12:44:55

[gforney]

Hi Randy,

Thanks for the explanation. I didn't realize that using obstructions within one mesh
gave the true solution (although it now seems obvious). I will try that, and also run
the more complex version with  ver 5.4.

Dave

Original issue reported on code.google.com by readsalot7 on 2009-09-04 18:56:49

[gforney]

Randy,

my question did not refer to a special case. I just try to understand in what cases

I can be sure of getting comparable outcomes in multi mesh cases.
Kevins and your comment helped a lot.

Thanks
Boris

Original issue reported on code.google.com by Info@F-Sim.de on 2009-09-07 13:57:12

[gforney]

Boris,

Thanks.  I just added the comments mentioned above to the Tech Guide.

Randy

Original issue reported on code.google.com by randy.mcdermott on 2009-09-07 14:33:46

[gforney]

I am transferring this Issue to Randy. You can keep it open if you like.

Original issue reported on code.google.com by mcgratta on 2009-09-09 18:14:40

[gforney]

Boris, Dave,

Please let me know if this issue can be closed.  We are aware that the pressure
solver still needs work for multi-mesh calculations, but this is addressed by other
issues.  If we have convinced ourselves there is not a bug in PC, then I think we
should close this one.

Thanks.
Randy

Original issue reported on code.google.com by randy.mcdermott on 2009-09-09 18:20:55

[gforney]

Dave,

Any progress on this issue?

Thanks.
Randy

Original issue reported on code.google.com by randy.mcdermott on 2009-09-15 20:39:50

[gforney]

LOL, well, yes and no. I had decided to dispense with the pressure correction feature

on my larger mine model, as the results seemed acceptable. Just as a formality I ran
it 
using ver 5.4 and I got a numerical instability in a model that ran fine with 5.3.1.
I 
am waiting until our cluster is updated to 5.4.1 and I will see if it still crashes.

Dave 

Original issue reported on code.google.com by readsalot7 on 2009-09-15 20:53:41

[gforney]

Ugh.  Sorry.  What to send me the case?

Original issue reported on code.google.com by randy.mcdermott on 2009-09-15 21:47:11

[gforney]

Dave,

Thanks for sending the case.  I have not had time to really study it, but from a
glance at the image you sent it looks like things are going unstable at the mesh
interfaces in the tunnel.

Whether PC is turned on or not it seems to me that there is a better way to mesh
these junctions.  I have attached a quick test case that shows how I would build the
mesh at junctions where the tunnels intersect.  Of course, this exact configuration
is not the solution to all problems, but as I was mentioning before, this idea of
keeping the flow orthogonal to the mesh interface is the basic principle.

Meanwhile, I'll run your case and see if I can get it to work.

Cheers,
Randy

Original issue reported on code.google.com by randy.mcdermott on 2009-09-16 17:10:50

---

• Attachment: junction.fds
• _Attachment: junction_PC=T_0109.png
  _

[gforney]

Hi Randy,

I will try your solution. (I was trying to avoid more meshes but I don't
think it can be helped.

Thanks

Dave

Original issue reported on code.google.com by readsalot7 on 2009-09-16 17:39:04

[gforney]

PC not being developed further.

Original issue reported on code.google.com by randy.mcdermott on 2010-04-06 20:53:01