Particle path integration

[chris]

I'm sure there's a way to do this somehow, but since I have no clue
how to go about it, nor any appreciation of the amount of work
involved, here it is:

I have a simulation for which I started thinking about particle path
integration. It's not critical, but it sure would be very nice to get
these results on top of everything else. I've seen examples where an
element is added to the solution vector (ie, using add2W, for
vorticity) and auxiliary code is patched to handle the new component
at every integration step. But my understanding is, this mechanism
adds one value PER CELL for the entire flow field, which is usually
what's required. What I really need is to define ONE set of values
X,Y,U,V (representing a single particle) PER TIME STEP, and then add
an auxiliary drag code to integrate these four values at every time
step. In reality, having multiple 4-component vectors would allow me
to handle multiple particles in a single run, but the point remains:
these are not field variables...

Is this in any way a possibility? Or was the Christmas punch too
strong for me?
(I'm seeing all kinds of problems here: how to initialize the values,
how to declare and store them in code, and in the results for that
matter. How to access them when needed, 'plot image' won't work no
more...)
Thanks!

[James Quirk]

Chris,

On Tue, 5 Jan 2010, chris wrote:

> I'm sure there's a way to do this somehow, but since I have no clue
> how to go about it, nor any appreciation of the amount of work
> involved, here it is:
>
> I have a simulation for which I started thinking about particle path
> integration. It's not critical, but it sure would be very nice to get
> these results on top of everything else. I've seen examples where an
> element is added to the solution vector (ie, using add2W, for
> vorticity) and auxiliary code is patched to handle the new component
> at every integration step. But my understanding is, this mechanism
> adds one value PER CELL for the entire flow field, which is usually
> what's required. What I really need is to define ONE set of values
> X,Y,U,V (representing a single particle) PER TIME STEP, and then add
> an auxiliary drag code to integrate these four values at every time
> step. In reality, having multiple 4-component vectors would allow me
> to handle multiple particles in a single run, but the point remains:
> these are not field variables...
>
> Is this in any way a possibility? Or was the Christmas punch too
> strong for me?

No your Wassail was not too strong. There's no convenient canned solution
to your problem, but the basic idea would be to append a customized step
to the integration sequence so as to take care of the movement of the
particles.

> (I'm seeing all kinds of problems here: how to initialize the values,

The particles would be initializsed in the problem setup.

> how to declare and store them in code, and in the results for that

and the "code" would live inside the patch-integrator, which is yours
to do as you so wish. After all, it's just a shared-object which
is sucked in on the fly, and it can be crafted anyway you want.

> matter. How to access them when needed, 'plot image' won't work no

plot image will work as usual, for the field solution. But you will need
custom plotting routines to take care of the particles.

James
> more...)
> Thanks!
>
>

[James Quirk]

Adobe Reader 9.3 is now available and I would recommend that
people upgrade as soon as possible. It's also worth noting
that AR8, and below, are no longer supported by Adobe for Linux, see:

http://blogs.adobe.com/adobereader/2009/12/adobe_reader_and_acrobat_versi.html

and so I too will no longer be supporting them in AMRITA.

James

[James Quirk]

Chris,

Attached is a script, run_particles_v1, that is a first-cut attempt at
integrating particle paths. As it stands, the integration can cope with
multiple grid levels. But if you take a look at the logfile,
logs/particles, which is arranged as (iteration count, particle time,
eulerian solution time) you'll see there is a small integration error.
This arises because of numerial round-off. For example, sometimes a
particle will lie on a patch boundary and so be missed, or counted twice.
Nevertheless, if you take a look at the animation produced, schlieren.swf,
you'll see the integration is qualitatively correct.

Looking to the future, if there is sufficient interest, particle
support could be added directly to AMR_SOL which woud greatly reduce
the burden on the script writer.

James

[chris]

James,
I started dissecting the script, and I think I might have found a
major problem with the general auxiliary code machinery by accident.
Hopefully, you'll know where the problem is.... and note that it
doesn't have anything to do with the tracking stuff...

To understand this, you have to know that program folds and me just
don't mix. So the first this I do whenever I get my hands on anything
is to remove them and streamline everything to reduce it to it's
minimalistic version. Then the learning begins...

...well, that's what I did with 'run_particles_v1'. As is, I can run
the script just fine. But there's a fold within the fortran code in
between lines 312 and 323. Take the original script, kill these two
lines, and on my machine the compilation process just hangs. (I spent
the last 4h tracking the hang to that specific fold...) Remove any
other fold within the code, and the whole thing compiles just fine.
When I say 'hang', it means I let it go for a minute, then stop it. It
never takes that long when things are ok.

And this is not a fortran indentation deal: removing the offending
fold, code/f77src/roe_fl.F looks all right. But take a look at code/
f77src/roe_fl.f: it's truncated in the middle of an include file! It's
as if the very last code parsing process before compilation choked on
something (string too long? blown stack?)

I'm not sure if anyone will be able to replicate behavior, or if
there's a reason for that specific fold to be mandatory. I understand
some are, but in this case, it looks very much optional to me...
Chris

[James Quirk]

Chris,

On Thu, 21 Jan 2010, chris wrote:

> James,
> I started dissecting the script, and I think I might have found a
> major problem with the general auxiliary code machinery by accident.
> Hopefully, you'll know where the problem is.... and note that it
> doesn't have anything to do with the tracking stuff...

There's a bug in amrf77's preprocessing phase.

>
> To understand this, you have to know that program folds and me just
> don't mix. So the first this I do whenever I get my hands on anything
> is to remove them and streamline everything to reduce it to it's
> minimalistic version. Then the learning begins...
>
> ...well, that's what I did with 'run_particles_v1'. As is, I can run
> the script just fine. But there's a fold within the fortran code in
> between lines 312 and 323. Take the original script, kill these two
> lines, and on my machine the compilation process just hangs. (I spent

replace the line:

IF((I.GE.IW).AND.(I.LE.IE).AND.(J.GE.JS).AND.(J.LE.JN)) THEN

by:

IF((I.GE.IW).AND.(I.LE.IE).AND.
X (J.GE.JS).AND.(J.LE.JN)) THEN

and the script will run. I haven't yet figure out why the problem
occurs, but I'll get back to you when I have,

[chris]

James,
With respect to the fortran 'notrefined' function, I can't pretend to
understand everything that's going on in there. There are a ton of
variables which are just plain new to me... But having worked out part
of what it does, I think there might be a problem with lines 305-306:

do gnof=1,nga(L+1)
grfd=gp(L+1) + gnof
...

If I understand, the number of finer grids are scanned, and inside,
grfd is a grid index inside the master list.

The thing is, if level 0 was defined with 4 patches, then gp(0) is 0,
and nga(0) is 4, so grfd should go from 0 to 3... and it currently
scans 1 to 4. (+ gnof always results in +1 since the scan starts at 0)

Shouldn't these lines be
do gnof=0,nga(L+1)-1
grfd=gp(L+1) + gnof

or
do gnof=1,nga(L+1)
grfd=gp(L+1) + gnof - 1

??? (notice the -1 in each case)

Looks to me like it currently scans everything but the first grid on a
given level ALONG with the first grid of the next level. Could this be
the real reason why particles are missed?
Chris

>  run_particles_v1
> 20KViewDownload

[James Quirk]

Chris,

>> I started dissecting the script, and I think I might have found a
>> major problem with the general auxiliary code machinery by accident.
>> Hopefully, you'll know where the problem is.... and note that it
>> doesn't have anything to do with the tracking stuff...
>There's a bug in amrf77's preprocessing phase.

The problem is in the file:

$AMRITA/tools/perl/amrpp/clean_f77.pl

replace line 25:

elsif($long_line =~ /[\=,\,\+\-\/\*]/) {

with:

elsif($long_line =~ /[\.\=,\,\+\-\/\*]/) {

and the script will run.

James

[James Quirk]

Chris,

> To understand this, you have to know that program folds and me just
> don't mix. So the first this I do whenever I get my hands on anything
> is to remove them and streamline everything to reduce it to it's
> minimalistic version. Then the learning begins...

It's your perogative to not like program folds. But be clear, the examples
I post here are intended to be viewed in a fold-compliant editor and to
view them as a regular linear-listing will miss the point of their
construction. So much so, your "learning" will be hindered to the point
that you might as well stop using AMRITA.

James

[Bijan B]

Hi James,

I would like to continue working on this particle tracking script. Hence, just in the very first steps of digesting what the script does, I tried to run it. As the necessary library files, I added the EulerEquations.amr and ShockWave.amr in my folder as you can see attached in the zip file to the message. But when running it, I receive an error saying that the solver does not exist:

Error at line 37 of file /home/Bijan/AMRITA/AMRITAv3.05/stdlib/system/Compile.amr:
AMRITA::system -- command failed!

Line 37 is:
}

error near:
end of line

Error at line 343 of file run_particles_v1:
solver doesn't exist!

Line 343 is:
solver  code/roe_fl

error near:
code/roe_fl

I am not sure whether this is happening because I am making a childish mistake and missing a necessary library file or something else that I don't know now. That would be very nice of you if you can help me out in this very first step.
Thanks in advance.

Regards.

Bijan

[James Quirk]

Dear Bijan,

Try running the script using:

    amrita -sys verbose run_particles_v1

this will show that the script is failing when it tries to compile the code, roe_fl .

Something in the auxiliary code used to track the particles, see line 189 onwards,

is not sitting comfortably with the version of gcc on your system; whereas it compiles

fine at my end with gcc-4.5.2 .  Also note that there is no need to ship the files EulerEquations.amr and SchlierenImage.amr, as they are unchanged from 

those in AMRITA's standard-library. Lastly, It would also be better if you sent

me a mailit, rather than a zip file. For that way I could check the version

of AMRITA you're using and therby determine if you're impeded by

a bug that has already been fixed in my master copy.

Best,

James

--
You received this message because you are subscribed to the Google Groups "amrita-ebook" group.
To unsubscribe from this group and stop receiving emails from it, send an email to amrita-ebook...@googlegroups.com.
To post to this group, send email to amrita...@googlegroups.com.
Visit this group at http://groups.google.com/group/amrita-ebook.
For more options, visit https://groups.google.com/groups/opt_out.

[Bijan B]

Dear James,
Thanks very much for your considerations. I tried the "amrita -sys verbose run_particles_v1" and still the same error occurs. Therefore, I have attached the mailit version to this message so that you can take a look in case you have time. Thanks a lot in advance for your help.
Regards.
Bijan

[James Quirk]

Bijan,

The mailit tells me that you're using AMRITAv3.05_R19-11-2011,

which is useful. But I was hoping you'd send me the script's

STDOUT together with the version of gcc you're using so

that I can diagnose the compile error.

James

[Bijan B]

James,
Sorry that I didn't provide those info at my previous message. The version of the gcc I am using is "gcc-4.7.2-2.fc17.x86_64" and also I have attached the STDOUT of the script to the message (if this is the correct thing you mean by the stdout).
Thanks.
Bijan

[James Quirk]

Bijan,

Do:

   cd code

   amrita -sys verbose roe_fl.mk > 4james

and then send me the 4james file. 

Thanks,

James

[Bijan Borzou]

James,
Attached you may find the 4james file.
Thanks.
Bijan

[Bijan B]

James,
It seems that for some reason the 4james does not attach to the message. Therefore, I have attached the 4james.txt to it here.
Thanks.
Bijan

To unsubscribe from this group and stop receiving emails from it, send an email to amrita-ebook+unsubscribe@googlegroups.com.

To post to this group, send email to amrita...@googlegroups.com.
Visit this group at http://groups.google.com/group/amrita-ebook.
For more options, visit https://groups.google.com/groups/opt_out.

--
You received this message because you are subscribed to the Google Groups "amrita-ebook" group.

To unsubscribe from this group and stop receiving emails from it, send an email to amrita-ebook+unsubscribe@googlegroups.com.

[James Quirk]

Bijan,

OK. There's no declaration for GRD in the routine I_particles and J_particles, as

can been seen by the error message:

AMRITA::system { verbose mode
   g77 -O3 -w -fPIC -fno-f90 -fugly-complex -I/usr/include \
   -I/home/Bijan/AMRITA/AMRITAv3.05/include/f77 \
   -I/home/Bijan/AMRITA/AMRITAv3.05/src -I/include/f77 -I. -I.. \
   -I/home/Bijan/.amrita/include/f77 -I/include/ -Dserial_code -DLinux_x86_64 -r -c \
   f77src/roe_fl.f
   f77src/roe_fl.f: In subroutine `amr02_integrate_grid': f77src/roe_fl.f:1029: \
   SUBROUTINE I_PARTICLES(Nt,L,GRD,IM,JM,NG,DX,DY,W,CTIME,DT) 1 \
   f77src/roe_fl.f:2266: (continued): CALL I_particles(Nt , 2 Argument #3 (named \
   `grd') of `i_particles' is one type at (2) but is some other type at (1) [info \
   -f g77 M GLOBALS] f77src/roe_fl.f:1134: SUBROUTINE \
   J_PARTICLES(Nt,L,GRD,IM,JM,NG,DX,DY,W,CTIME,DT) 1 f77src/roe_fl.f:2307: \
   (continued): CALL J_particles(Nt , 2 Argument #3 (named `grd') of `j_particles' \
   is one type at (2) but is some other type at (1) [info -f g77 M GLOBALS] 
}

To fix this, edit the file run_particles_v1 and change line 216 from:

   AMRINT IM,JM,NG

to:

   AMRINT GRD,IM,JM,NG

Then repeat for line 257.

James

[Bijan B]

Thanks a lot James. That solved the issue. Now I am planning to fully digest what this script doing and afterwards apply the same thing for the particle tracking for detonation simulations using 2step solver. I may bug in future and asking for your comments then.
Once again thanks for putting time on it.
Regards.
Bijan

[Bijan B]

Hi again James,

First of all thanks a lot for your all helps up to now. It seems that I am in need of your instructions and help again. As I said, this week I tried to match the particle tracking aux code on my 2step detonation script and in this way faced some difficulties. When I run the two-step code with the aux code I again face the error "solver doesn't exist!" as you can see in the STDOUT file attached. In order to find where the error is coming from, I tried " amrita -sys verbose 2step.mk > 4james.txt" in the "code" folder and found out it is picking on something about mismatch of the precision of CTIME and DT at different places. Hence I tried defining them as AMRDBL in lines 376 and 417 but did not make the script going again. I have attached the mailit, STDOUT, 4james.txt and 2steplib folder to this message so that if you have time, once again you do me a great favour and take a look at it. Also as a reminder my gcc version was "gcc-4.7.2-2.fc17.x86_64.

Thanks a lot in advance for your helps.

Regards.
Bijan

[James Quirk]

Bijan,

From the script you sent me it is clear you are not using amrgi in the construction of your 

AMRITA script, in which case I reserve the right not to help you, until you do. This might 

seem very harsh of me. But consider things from my perspective. By not using AMRITA

in the way it was intended, you have made your script unnecessarily hard for a third-party 

to digest. Therefore even if I fix the code for you, it will not be in any shape to benefit

others: so what is the point?

Clearly this response is not the one you wanted. But be clear, AMRITA is designed

to help those who help themselves. Now if we were co-located I could sit down with you

and show you a before and after of your script. That way you would see there is

scientific method to my insistence and I'm not just being grouchy. However,

as we're not co-located  I fully appreciate why you will be disappointed.

Therefore I would like to refer you to the UK parliamentary report, ``Peer Review in

Scientific Publications":

http://www.publications.parliament.uk/pa/cm201012/cmselect/cmsctech/856/85602.htm

and request that you ponder why you have an intellectual obligation to make your

work as transparent as possible. 

James

James

[Matei Radulescu]

James,

We were not able to make Origami work properly for a number of years now (it last worked on FC10), and I am not sure what is wrong.  We tried installing various packages hoping it would fix it, but there seems that some incompatibilities remain between current RPM’s and the ones intended for the good working of AMRITA.  Perhaps if you could help me troubleshoot the issues, then it would be beneficial to all users who install AMRITA to new Linux installations.

Matei  

[James Quirk]

Matei,

The attached origami works fine in 64bit mode on Linux Mint 13, Ubuntu 11 and Ubuntu 12.

Place it in the directory $AMRITA/src3p then run:

    mv origami old_origami

    tar zxvf origami.tar.gz

    amrmake -vebose src3p::origami

If the link complains that -ltermcap is missing, install the version given here..

To test amrgi, use the -dryrun option as in:

amrcp Latex2eHead.amr

amrgi -dryrun Latex2eHead.amr

This will give you the system commands that are run. At my end, I get:

export ORIGAMIHOME=/home/jjq/AMRITA/AMRITAv3.09/src3p/origami/keys

xterm -class AMrgi -name amrgi -ut -display :0.0   -e /home/jjq/AMRITA/AMRITAv3.09/bin/serial/Linux/x86_64/O/origam

AmritaUtilize.amr ;

You can then try running them manually, and should amrgi crash: use -hold before the -e.

This will hold the xterm so that you can read the reported error message.

James

[Matei Radulescu]

James,
Before re-installing origami, i tried using the -hold option with my existing system when running the suggested command.  I get an origami window displaying the single message "segmentation fault". 
In the past, a window would flash and immediately close under any call of "amrgi".

I installed the origami package you provided.  It did not encounter any errors during compiling.  The same behavior persists.  Any idea of the potential cause?
Thanks,
Matei 

---

From: amrita...@googlegroups.com [amrita...@googlegroups.com] on behalf of James Quirk [j...@amrita-ebook.org]
Sent: Thursday, October 31, 2013 12:47 PM
To: amrita...@googlegroups.com

[James Quirk]

Matei,

Yes. Go to:

    $AMRITA/src3p/origami

and look at the file motif.C . It''s likely the problem is in the call to XtVaAppInitialize,

which appears at line 50:

         top_wid = XtVaAppInitialize(&app, "mamrgi", NULL, 0,

                                     &argc, argv,   NULL, NULL);

or somewhere in the block of code that immediately follows. To debug things,

try replacing motif.C with the attached version. It turns off some non essential

code to leave just the above top_wid creation. Recompile using:

    amrake src3p::origami

and then test as before. If that also fails, try replacing:

      const int  argc=1;

      const char *argv[1]={"Amrita::Origami"};

by:

      static int  argc=1;

      static char *argv[1]={"Amrita::Origami"};

James 

James

[Matei Radulescu]

James.
The suggested steps yield the same segmentation fault. 
Matei

---

From: amrita...@googlegroups.com [amrita...@googlegroups.com] on behalf of James Quirk [j...@amrita-ebook.org]

Sent: Monday, November 04, 2013 9:30 AM

[James Quirk]

Matei,

Wrap the creation of top_wid inside of a pair of fprintf's:

    fprintf(stderr,"before top_wid\n");

    fprintf(stderr,"after   top_wid\n");

to verify that the problem is indeed in the creation of the top_wid.

To see the messages you will need to run origami manually

with the -hold option.

You should should also tar up the origami binary:

   $AMRITA/bin/serial/O/Linux/.../origami

and send it to me so that I can run it through a debugger.

James

[Matei Radulescu]

James,
I am a bit confused. 
I input the fprintf statements as per:

CODE THAT I INPUT:
fold::amrcc { amrgi_widget
   Widget amrgi_widget() {

      fprintf(stderr,"before top_wid\n");

      Widget ctext;

      static int  argc=1;
      static char *argv[1]={"Amrita::Origami"};

      if(top_wid==NULL) {

         top_wid = XtVaAppInitialize(&app, "mamrgi", NULL, 0,
                                     &argc, argv,   NULL, NULL);

#ifdef QDEBUG
         ctext = XmCreateText(top_wid, "c_text", NULL, 0);
         XtVaSetValues(ctext,
            XmNeditMode,         XmMULTI_LINE_EDIT,
            XmNeditable,         False,
            XmNcursorPositionVisible,  False,
            XmNcolumns,          75,
            XmNrows,             7,
            NULL);

         XtManageChild(ctext);
         XmTextSetString(ctext,
         "Ferranti is willing to waive all rights to the folding editor ``origami''    \n"
         "so that it may be freely distributed as public domain software subject       \n"
         "to the following conditions:                                                 \n"
         "(1) A program that uses this software must display on the screen on startup: \n"
         "    originally devised by  Martin Green, Ferranti Ltd, Cheadle Heath,        \n"
         "    Stockport, England                                                       \n"
         "(2) The word ``ORIGAMI'' is displayed as well.\n");
         /*
         CreateForms (top_wid);
         XtRealizeWidget(top_wid);
         redisplay();
         sleep(2);
         XtUnrealizeWidget(top_wid);
         redisplay();
         */
#endif

      fprintf(stderr,"after top_wid\n");
      }

      return top_wid;
   }
}
END OF CODE THAT I INPUT

This time around, when I type "amrgi" in the terminal, i get an orgami window.

When I type "xterm -class AMrgi -name amrgi -ut -display :0.0 -hold -e /home/matei/AMRITA/AMRITAv3.05/bin/serial/Linux/x86_64/O/origami Latex2eHead.amr ;"

i get an origami window saying "Environment variable ORIGAMIHOME not set".

When i remove the "fprinf"s above, I get the segmentation faults.

What do the fprintf's do to prevent origami from crashing?

Matei

___________________________________________________________________________________

[James Quirk]

Matei,

Note the output of amrgi's -dryrun. There are two commands: the first sets ORGAMIHOME;

the second runs the xterm. So if running amrgi manually then you also need to set the

environment variable.

James

[Matei Radulescu]

James, 

Noted.

The fact remains that origami works with fprintf’s statements in the location indicated in my previous mail, and fails otherwise.  Short of having an ugly fix by keeping the fprintf statements in, any idea what is causing this and how to fix it?

Thanks,

[James Quirk]

Matei,

You didn't send me your origami binary, as requested.

But as a stop gap, you might try a null fprintf, as in:

    fprintf(stderr,"");

or you could edit:

   $AMRITA/Amrita/keywords/tools/amrgi.pl

and insert after line 1038:

   -e $CMD

   2> /dev/null

to redirect the standard error away from the screen.

James

[James Quirk]

Matei,

In motif.C, you could also try replacing:

    const char *argv[1]={"Amrita::Origami"};

by:

    const char *argv[]={"Amrita::Origami",NULL};    

and see if that allows you to remove the fprintf's.

James

[James Quirk]

Matei,

I've run your binary through a debugger and it is indeed crashing out in the call to XtVaAppInitialize.

Now attached is a tar file 4matei.tar.gz that contains:

   origami1.C

   motif.C

   JJQ/origami

Use the two C files to replace those in $AMRITA/src3p/origami and recompile with:

   amrmake src3p::origami

This version should work as it uses the system argc and argv rather than my

dummy versions. But should this new version fail then you can use the binary 

that I create at my end, JJQ/origami, to see if there is a problem with your

compilation. To do so, cp JJQ/origami to:

$AMRITA/bin/serial/Linux/x86_64/O/origami   

and then issue the amrgi command. Note my binary will fail if your Linux system

is older than mine, so there is no guarantee it will work: but it's worth a shot. 

James

[Bijan B]

Hello James,
You were quite right about using the amrgi to keep the script transparent for also third parties to use. Therefore, this week I worked the script out in the amrgi and I now think that it is much better than before even for me myself. But since it was my first experience of working in amrgi, I will be more than happy to receive any comment to improve my performance in that environment.
Anyways, hope that now the script has the minimum requirements from your point of view to help me. So as told you before, I have tried to match the particle tracking aux code on my 2step detonation script but I have received the error message  "solver doesn't exist!". To find where the error is coming from, I tried " amrita -sys verbose 2step.mk > 4james.txt" and found out there is a problem about mismatch of the precision of CTIME and DT at different places. I have attached the mailit, STDOUT, 4james.txt and the 2steplib folder to this message. It will be very nice of you helping me in improving any part of this process.
Thanks a lot again.
Bijan

[James Quirk]

Bijan,

Your 2Step2Drt script is not a bad effort, but there are a few things you could tighten up on

and attached is my cleaned up version. Most of the changes are cosmetic so as to improve

the way the script reads. But note the changes to SetupZNDWave: I removed the call

to GetInput and added to the defaults parameter so that the information flows

naturally from the Study:: namespace. 

James

  

[Bijan B]

Thanks a lot James for all your comments and helps. I will also keep working on it and will share any possible future progress or issue with the group.
Regards.
Bijan

[Bijan Borzou]

James,
Hi again,
I kept working on the script and I found out that there is still an issue with it before being good to use. While working, I found out that no data is outputted in the file logs/particles and I asked myself why? Then finally, by printing the values of "DT" being fed to the aux code (Line 365), I found the values are not correct (unreasonably high) and that's why the particles are not tracked. The only thing right now coming to my mind about why this is happening, is that I think it may be something still wrong with the AddIntegrationSteps or the matching between the solver the aux code. Once again, it would be very great favour from you if you can comment on that and guide me again on this.
Thanks again.
Bijan

[James Quirk]

Bijan,

Check out the original script, it contained a call:

call code/roe_fl:f77::sync_particles

that did the printing of the particle positions. Said call is missing from

your latest script.

James

[Bijan Borzou]

James,

Thanks. You were right. I had forgotten to call the sync_particles. I did that but unfortunately after doing that, I received the message of package doesn't exist! :(

Line 240 is:
call code/2step:f77::sync_particles

as you can see in the STDOUT. I checked the verbose mode also, and to me everything looked fine. Do you think that may be because still something in the aux code is not sitting comfortably with my gcc or I am impeded by a bug that has already been fixed in your master copy.

I have tried it with both the combinations of (Amrita v3.05 and gcc-4.7.2-2.fc17.x86_64) and (Amrita v3.03 and gcc-4.1.2).

Thanks again.

Bijan

[James Quirk]

Bijan,

You're probably invoking the 2step package from a directory

other than the one in which it was built and so the call

cannot locate the necessary shared object. As a quick test,

add the following as the first line of your script:

autopath + $amrita::CWD

assuming that's the directory where code resides.

James

 

James

[Bijan Borzou]

James,

Thanks for your previous comment. So as to date the code has been relieved from all the programming errors but still something is remained.  The time step computed by the patch integrator is totally off. So In the last week I was digging around to find out why it computes a correct one in your Euler Equations while I am not getting it right in my Reactive Euler one and the result is still staying in confusion about it :(. To get an idea of what the computed time step values are, I put a print command in line 385 of the script that you can see its results in the STDOUT attached to the message.

Like always, your technical comments are of invaluable worth for me to proceed.

Regards.
Bijan

[James Quirk]

Bijan,

You are using a custom EquationSet and so there are a

number of things that you, or your colleagues, could

have messed up.

First, check that you have the initial conditions set up correctly

by adding the following after the makefield command:

  fold::amrita { check initial conditions

     minmax Y[] -> y1,y2

     set ymid #= 0.5*($y1+$y2)

     foreach Q (RHO,U,V,P,Zi,Ze)

         printfile t0/$Q.dat

         along y=$ymid print X[],$Q[]

     end foreach

     exit

  }

so as to make sure that the profiles you fed in are what you expected.

This will check that the mappings in your ReactiveEulerEquations

from primitive variables to conservative variables and back

again are working.

At the same time check that the problem specific quantities

Q,E,GAMMA,ETA and KE are consistent with what you fed in.

Then when that all checks out, you need to check that your

cusom bcg PartialDerivatives routine is implemented properly,

Note I can't be held responsible for any of this custom code,

so you should consult with you advisor to see who wrote

what and when.

James