[Nek5000-users] proj_ortho error in pipe flow

nek5000-users at lists.mcs.anl.gov nek5000-users at lists.mcs.anl.gov
Thu Sep 28 09:04:58 CDT 2017


Dear Steffen,


I believe this issue may have been resolved in an update to the git repo

last week.


Best,


Paul


________________________________
From: Nek5000-users <nek5000-users-bounces at lists.mcs.anl.gov> on behalf of nek5000-users at lists.mcs.anl.gov <nek5000-users at lists.mcs.anl.gov>
Sent: Thursday, September 28, 2017 7:40:27 AM
To: nek5000-users at lists.mcs.anl.gov
Subject: Re: [Nek5000-users] proj_ortho error in pipe flow


Hi Neks,

I might have fixed my proj_ortho error issue. At least it is running now without errors on a small test case on my local machine. However, I am very much unsure if what I was changing is correct.
Can you please confirm that my adjustments are reasonable?

In conduct.f when hsolve is called, I have adjusted the argument list like this:

-      napproxt(1) = laxtt  ! Fix this... pff 10/10/15
+      napproxt(1,ifield-1) = laxtt  ! Fix this... pff 10/10/15

            call hsolve  (name4t,TA,TB,H1,H2
      $                   ,tmask(1,1,1,1,ifield-1)
      $                   ,tmult(1,1,1,1,ifield-1)
      $                   ,imesh,tolht(ifield),nmxh,1
-     $                   ,approxt,napproxt,bintm1)
+     $                   ,approxt(1,1,ifield-1),napproxt(1,ifield-1)
+     $                   ,bintm1)

such that approxt and napproxt refers to each ifield, ie. temperature, passive scalar 1, passive scalar 2, ... similar to velx, vely, velz.


Accordingly, I have adjusted ORTHOT:

-      integer         napproxt(2)
+
+C Add another dimension to (n)approxt for each passive scalar and temp.
+      integer         napproxt(2,ldimt)
       common /trthoi/ napproxt

-      real            approxt(ktott,0:laxtt)
+      real            approxt(ktott,0:laxtt,ldimt)


and induct.f

-      napproxt(1) = laxtt
+      napproxt(1,ifield-1) = laxtt






On 09/14/2017 06:29 PM, nek5000-users-request at lists.mcs.anl.gov<mailto:nek5000-users-request at lists.mcs.anl.gov> wrote:

Date: Thu, 14 Sep 2017 15:34:39 +0000
From: nek5000-users at lists.mcs.anl.gov<mailto:nek5000-users at lists.mcs.anl.gov>
To: "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>
Subject: Re: [Nek5000-users] proj_ortho error in pipe flow
Message-ID:
        <mailman.770.1505403282.10190.nek5000-users at lists.mcs.anl.gov><mailto:mailman.770.1505403282.10190.nek5000-users at lists.mcs.anl.gov>
Content-Type: text/plain; charset="windows-1252"


Hi Steffen,


Thanks for bringing this to our attention.


Adam and I have been looking into this... (no doubt, it's something

stupid done by me awhile back).


Hope to have it resolved by next week.


Best,


Paul


________________________________
From: Nek5000-users <nek5000-users-bounces at lists.mcs.anl.gov><mailto:nek5000-users-bounces at lists.mcs.anl.gov> on behalf of 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: Thursday, September 14, 2017 8:18:27 AM
To: nek5000-users at lists.mcs.anl.gov<mailto:nek5000-users at lists.mcs.anl.gov>
Subject: Re: [Nek5000-users] proj_ortho error in pipe flow

Hi,

I have made some more tests to find the cause of this issue.
Attached is a laminar pipe flow simulation with temperature and one
passive scalar. The original setup is from Paul's "nusselt.tgz", where
he answered another question of mine.

I found that I can reproduce the same error I see in my turbulent
simulations when there is an additional passive scalar with a different
type of boundary condition, i.e. Neumann boundary condition at the pipe
wall for temperature and Dirichlet boundary condition for the passive
scalar.

Can someone please check my setup and tell me why this causes the
projection to fail?


I hope to save some computational resources by using the projection.
However, if it is not possible, I will keep param(94) = 0.

Kind Regards,
Steffen Straub

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/nek5000-users/attachments/20170928/84962990/attachment.html>


More information about the Nek5000-users mailing list