shock/detonation interaction with a ramp

[Matei Radulescu]

What would be the best starting point to start studying an example of
folded script looking at the problem of the interaction of a
detonation wave and/or an inert shock wave interaction with a ramp?
JJQ's vki second set of notes deal with such an example at some
length, but I wonder if the procedure and scripts have been improved
since then, and/or ported to the reactive case?

In a related way, the generation of html help files and generation of
mpeg movies detailed in the vki notes do not seem to work with my
installation of amritav3.00 on a 32bit fc7 installation. is that due
to some incompatibility with the older scripts, or simply an
installation issue on my part? When i installed it, all the
components seemed to work well, except some serious issues with the
GIMP; gimp-perl is not available for my system.

[James Quirk]

Matei,

On Tue, 27 May 2008, Matei Radulescu wrote:

>
> What would be the best starting point to start studying an example of
> folded script looking at the problem of the interaction of a
> detonation wave and/or an inert shock wave interaction with a ramp?
> JJQ's vki second set of notes deal with such an example at some
> length, but I wonder if the procedure and scripts have been improved
> since then, and/or ported to the reactive case?

AMRITA+AMR_SOL's operation is essentially independent of the EquationSet
and so if you have a ramp-script that works for the plain EulerEquations
it will automatically work with the ReactiveEulerEquations i.e there is
no porting in the classical sense. Now if you take a look at AMRITA's
big picture:

http://www.amrita-cfd.org/html/screenshots

you will see on the notice board (at about 11 o'clock) a single mach
reflection for a detonation wave interacting with a ramp. That particular
calculation, done back in 1993, used a body-fitted grid which is
set up in the fashion decribed in the VKI notes.

There is, however, an alternative approach you can follow which
uses a level-set technique on a Cartesian mesh. The examples:

amrcp latex/Chp2/method.3
amrcp latex/Chp2/method.4

show it working in the inert case. But you will need to fix
the following bug in AMRITAv3.00 before you can run them.
Hand-edit the file:

$AMRITA/Amrita/keywords/def/EquationSet/amr_sol.pl

After line 54:

$amrita->set_thistoken('amr_sol::NEQN', 0);

insert:

my $frame = "$STACK{$PROCnamebase}_";

This bug crept in when I refactored amr_sol so as to make it
easier to maintain.

>
> In a related way, the generation of html help files and generation of

The -html option described in the VKI noted has been deprecated.

> mpeg movies detailed in the vki notes do not seem to work with my
> installation of amritav3.00 on a 32bit fc7 installation. is that due
> to some incompatibility with the older scripts, or simply an
> installation issue on my part? When i installed it, all the

I would need to check up on the mpeg problem, but I know Hans
has been generating movies and so I guess it could be a local problem
at your end.

> components seemed to work well, except some serious issues with the
> GIMP; gimp-perl is not available for my system.

The gimp-perl interface is used to craft buttons and the like.
It's not needed to be able to run any of the examples in the VKI
notes, but I can always put together a tarfile containing
the necessary Perl modules.

James

>
> >

[Gary Sharpe]

> There is, however, an alternative approach you can follow which
> uses a level-set technique on a Cartesian mesh. The examples:
>
> amrcp latex/Chp2/method.3
> amrcp latex/Chp2/method.4
>
> show it working in the inert case.

James and I looked at a related problem of inert shocks and
detonations
driven by constant velocity wedges using this technique a couple of
years ago. One note of caution is that we found some solver dependent
issues - in particular the roe schemes didn't tend to the correct
shock/detonation angles in the far field. The solver that worked best
was the lax-friedrichs (W)ENO scheme, for which I think the level
set stuff was originally designed. As I recall James found there
was some "leakage" of info through the level set surface for the Roe
case.
This is all anecdotal, my only point in mentioning it is that if you
go down this
route this is a case where you definetly need to do solver studies
which amr_sol is designed for. I believe I still have the scripts
we used for this, which I can send to Matei if required, but
I can't vouch that they are well polished.
Cheers
Gary.

[James Quirk]

Gary,

> driven by constant velocity wedges using this technique a couple of
> years ago. One note of caution is that we found some solver dependent
> issues - in particular the roe schemes didn't tend to the correct
> shock/detonation angles in the far field. The solver that worked best
> was the lax-friedrichs (W)ENO scheme, for which I think the level
> set stuff was originally designed. As I recall James found there
> was some "leakage" of info through the level set surface for the Roe
> case.
> This is all anecdotal, my only point in mentioning it is that if you
> go down this

I'm guessing that the entropy-fix which is applied to the
contact wave to suppress the carbuncle phenomenon is the
culprit here.

James
> Cheers
> Gary.

[Matei Radulescu]

James, Gary,
Thanks for the information. Are the problems mentioned by Gary solely
associated with the level set method?

In the body fitted grid examples of the vki notes, would there be any
problems with the skewed grids? I assume that the more skewed the
grids become, the less accurate becomes the estimate of the fluxes at
the cells interface, am I right? For example, if one extends the
technique to simulate flow over a sphere, the cells near the front and
back of the cyclinder would be highly skewed and large errors would
ensue. In that case, I guess the level set method would be the better
choice. Right? The reason why I am asking is that I would also like
to look at shock/detonation problems interaction with cylinders.

matei

[James Quirk]

Matei,

>
> James, Gary,
> Thanks for the information. Are the problems mentioned by Gary solely
> associated with the level set method?

I would not worry too much about Gary's observations for now,
as setting up a script for a physical flow problem is largely
independent of the choice of patch-integrator. Thus you can
always try out multiple schemes on the one problem so as to
gauge the sensitivity of the observed results to the details
of the numerical method.

>
> In the body fitted grid examples of the vki notes, would there be any
> problems with the skewed grids? I assume that the more skewed the
> grids become, the less accurate becomes the estimate of the fluxes at
> the cells interface, am I right? For example, if one extends the

Yes, one could say that.

> technique to simulate flow over a sphere, the cells near the front and
> back of the cyclinder would be highly skewed and large errors would
> ensue. In that case, I guess the level set method would be the better
> choice. Right? The reason why I am asking is that I would also like

Yes and no. The level set method is inferior to the body-fitted
grid right at the cylinder's surface, but the Cartesian grid would
win out away from the body. So it's a case of "swings and roundabouts"
as we say in the UK. Anyhow, if you take a look in my thesis,
you'll see that a polar grid can give quite good results for
a shock wave interacting with a cyclinder. But I expect it would
not work so well for a detonation. But the beauty of AMRITA is
that once you're up to speed, you'll easily be able to try out
both approaches and so there is no need to feel compelled
to stick with one or the other.

> to look at shock/detonation problems interaction with cylinders.

James
>
> matei

[Shem]

For those interested, some results of inert shock reflections off a wedge and the corresponding script are attached. Comments are very welcome.

[James Quirk]

Dear Shem,

On Wed, 3 Apr 2013, Shem wrote:

> For those interested, some results of inert shock reflections off a wedge
> and the corresponding script are attached. Comments are very welcome.
>
>

Thanks for taking the time to submit your work for the benefit of others.

Now after a quick perusal of your attachment I have some comments which
at first blush might appear harsh, but if you mull over them then
I hope you will see that is not my intent and that the following is
strictly aimed at getting you to think about how you go about your
computational work.

Let's start with a question.

On a scale of 1 through 10: how well do you think you are using
the software services that AMRITA provides? Think carefully before
answering.

The evidence suggest that you are not helping yourself, or at least
you are swimming against the software services that AMRITA provides,
and so the correct answer might be much lower than you would expect.

So what is the evidence to support my comment?

Well there are a few clues in the file, ShockReflArcRamp.amrita .

First, I know you are *not* using the folding-editor, amrgi, shipped
with AMRITA. How? Well, for some program-folds you have used
a trailing-comment at the end of the fold e.g line 356 which reads:
} #"run simulation" . This is not possible with amrgi and so
you are presumably using a regular editor such as vi, emacs, etc.
The knock-on effect is that you cannot properly exploit AMRITA's
tree-based programming model and the code you write will be
harder than necessary for a third-party to digest.

This might all sound as if I'm knit picking, but it really
cuts to the heart of AMRITA's co-operative design.

Here, for instance, I'm attaching a draft of a PDF I'm currently
constructing, see jjq-mm2013.pdf . You sent me a zip file containing
a PDF and a script. I'm sending you a PDF that contains a script
and an actual simulation. Yes, when viewed using Adobe Reader 11,
on Windows or OSX, the PDF itself contains a multi-threaded,
parallel simulation.

Of course, as it stands my PDF lacks the commentary needed to bring
out the significance of what it is trying to convey. But I know
from your PDF: (i) you have access to an OSX machine; (ii) you
constructed the LaTeX by hand, rather than using AMRITA's fold::latex
mechanism.

From (i) there is a hope you will be able to view my PDF as intended,
although your Adobe Reader might need upgrading. From (ii) I know
that you have not embraced AMRITA's document-centric, computational
philosophy. See, for instance, http://www.amrita-cfd.org/doc/amr2003 .

Returning to your script, there are plenty of little clues that
your are not helping yourself.

Consider the first fold, "define array sizes." From the commented out
values you are likely continuously editing the script based on the size of
problem you want to run, which is error prone. You also have some
nonsensical values, such as NGHOST=20 and NL=100, which suggest you do not
fully understand their purpose.

NGHOST sets the number of ghost cells used to implement boundary
conditions between mesh patches. For the patch-integrators you are
using, the default value of 2 is sufficient. For a high-order WENO
scheme you would need to use NGHOST=3, but under no circumstances
would you ever need to use a value of NGHOST=20 (your commented
out value) and the computational overheads of so doing would render
the simulation incredibly inefficient, even supposing it actually ran.

Similarly, your commented out value for NL (100) is ludicrous.
NL sets the maximum number of allowable grid levels. Now should
you try to run with 100 grid levels, the finest mesh would (for
a refinement ratio of 2) be integrated 2^100 times for every
integration of the base mesh. The upshot for a non-trivial
simulation is that somewhere amongst those 2^100 integrations,
the flow would become unstable as it would be using a fixed
time step chosen at the beginning of the integration sequence.

Your value for NGD (2.8M) is also suspiciously high, but is
less heinous that those for NGHOST and NL.

Moving on to your InertShockReflectionProblem. As you've not
embraced program folds, the procedure is folded sub-optimally.
Consider, the solution field fold. It is inside out.
Both your scenarios result in the same setfield commands
and so you'd be better off placing the scenario logic
deeper down the fold-tree than the setfield commands,
that is you would use something along the lines of:

fold::amr_sol'SolutionField {
fold::amrita { get states
# enter logic here
}
setfield W'quiescent
setfield W'post_shock distSW<0
}

Note when viewed with amrgi, a thirdy-party would see the SolutionField
construct first, with which they'd be familiar. And they would only need
to dive further down the fold-tree should they be interested in the
details of how the states where obtained. The same observation applies
to your BoundaryConditions construct.

I suggest you have a stab at re-folding your SolutionField and
post the results here, I'll then critique it and post the
recommended approach.

I'll end here as this e-mail is getting quite long. But I would like
you to mull over the above points. There are numerous other observations
I coud have made, which come from 30+ years of programming. My aim
is not to belittle your efforts. They're purely to impress upon
you the need to produce polished scripts that stand the test of time.
I also suggest you talk matters over with your supervisor from
the perspective of the legacy you are leaving for his next student
i.e. is it all that it could be.

Again, thank you for taking the time to post your work. If more
people did, you would have more examples to show you which
script approaches work and which don't.

Best regards,

James

[Shem]

Hi James,

Thank you for your feedback. I will work on the script based on your suggestions.

As for the results, I was hoping you could enlighten me on some of the reasons that the internal wedge and south-boundary wedge would give different results. You mentioned the entropy fix applied to the Roe solver might be to blame, but what about the others?

[James Quirk]

Shem,

Try putting your verification hat on and ask: "am I solving the equations
correctly?" So the first step is to look at a stylized example, for which
you know the answer, and see if the numerical machinery is giving the
expected answer. For instance, you could try running a 2D problem where a
planar shock reflects from a wall in a 1D fashion, for which you have an
analytic solution. The reflection can then be studied using both the
regular reflect boundary condition and the AXS internal boundary condition
so as to ascertain if the latter "leaks." You could also automate a study
where the AXS boundary varies from lying at a cell interface to being at a
cell-centre, so as to observe the associated numerical errors.

The above could also be done using a variety of flow solvers
and not just the flux-limited'operator split one. For example,

plugin amr_sol
EulerEquations
BasicCodeGenerator {
solver = 4shem
scheme = first-order'finite-volume
flux = bcg/hlle # also efm, godunov, roe, roe2, ausm, ...
}

Note the difference between roe and roe2 (one applies the Harten
entropy fix to the contact the other doesn't). In all cases
you'll likely see a standing wave error at the wall, which
is described in the literature as wall-heating.

Then when you've exahusted the first-order schemes you
could repeat the exercise with kappa-muscl'finite-volume .
Note the use of finite-volume rather than operator-split,
as in your original script. A split scheme is likely
to be worse than a unsplit one, when using AXS, for a boundary
that is oblique to the mesh.

Also note the "t" in AMRITA's name: it stands for "teaching."
AMRITA will allow you to teach yourself, but only if you
take the time to learn to use it efficiently. That way,
all the above can be automated allowing you to sample
a much larger range of cases than if you did them by hand.

Here it should be noted that your original script produces
PostScript files which you would have needed to convert
to PDF before you could add access them in your pdfLaTeX.
Now I don't no how you did it, but be aware that to create
PDF directly just use a .pdf suffix in your plotfile command.
Also be aware of the pushcwd and popcwd commands:

amrhelp pushcwd

They provide a much cleaner means of running a parameter
study where the output is placed in a directory tree than
by giving the individual plotfiles paths.

James

[Shem]

I've attached a script which tests four boundary conditions for some different solvers, as you suggested. It produces a (very rudimentary) document with the initial conditions and the density and pressure plots. It runs a two-dimensional domain where the density and pressure plots are taken along the center after a shock reflects off an end wall. I've also attached the document in case someone doesn't want to run it. Reducing the resolution greatly speeds things up.

I am worried about the results because, as you can see from the initial grid where the level-set curves have been plotted, the internal boundary seems to have problems at the corners and around the center. I built the boundary in a piece-wise fashion where the closest boundary to any point on the grid would be selected. I believe this is the reason the Godunov scheme fails (in some cases) on the off-grid and angled boundaries.

With respect to what we see with the Roe f.v. scheme (the density plot is not included in the document I've attached but can be found in "./results/EB/roe-fv/dens", for example), this is the carbunkle effect which occurs without the entropy fix?

Unfortunately, it seems Adobe has abandoned their PDF reader for Linux (the last version 9.5.4 cannot take advantage of your PDF) and we do not have AMRITA installed on any OSX or Windows computers. Does anyone know of an alternative, compatible reader?

Again, I would like to thank you for your time.

[James Quirk]

Shem,

Sorry for being slow to reply, but I've been preoccupied with other
business. I've now taken a quick look at your script and it needs some
remedial work, which I will try to do this evening. In the mean time
you should try to figure out why the embedded boundary method doesn't
like corners. Sit down with a pencil and paper and sketch out waht
it is doing and the answer shpuld leap out you from the page;
it's a well known deficiency.

James

[James Quirk]

Shem,

You should also take a long hard look at how you've constructed
the InertShockReflectionProblem procedure. There is *nothing*
to be gained by writing:

fold::amr_sol'RefinementCriteria{ Set adaptive mesh refinement criteria

when a plain:

fold::amr_sol'RefinementCriteria {

would suffice. If you think I'm being picky, you miss the point
of the notion of programming patterns. Using amr_sol named blocks,
all flow problems can and *should* be folded to read:

... Domain
... BoundaryConditions
... SolutionField
... MeshAdaption
... RefinementCriteria

Any departure from this pattern makes it harder for a third-party to
get to grips with your script.

Also, whenever you find yourself setting system tokens, as in your
"Initialize LateX" fold:

set amrita:latex::dir = document
set amrita:latex::file = $amrita:latex::dir/boundaries.tex
set amrita:latex::PS = $amrita:latex::dir/ps
mkdir $amrita:latex::dir

you should be aware that you are fighting against the system.

The call:

Latex2eHead {
dir = document
file = boundaries
}

does all of the above for you. So I'm not sure why you thought
you needed to do it by hand.

Also, I'm not sure why you're running gnuplot explicitly, as in:

execute gnuplot dens.gnuplot

when you can use the pre-supplied library routine:

GnuPlot {
fold::param'script {
# enter your gnuplot commands here
}
}

Note the library routine is "clever" enough to fix backwards
incompatibilities in gnuplot. But by going it alone, you can't
take advantage of such features.

Your use of {push,pop}cwd is also not as intended.

First, the two commands:

pushcwd results
pushcwd $myScenario

should be combined:

pushcwd results/$myScenario

Note that pushcwd creates subdirectories as needed.

Second, when using folds, there is no execuse for a pushcwd/popcwd pair
not appearing close to one another. Thus you should have written

something along the lines of:

fold::amrita { run simulation
pushwd results/$myScenario
... here
popcwd
}

Since my first message, have you embraced using amrgi?

If not, you can't expect to benefit from AMRITA's fold-based methodology.

As before, the above is not meant as criticism. Think of it as a prod to
get you think about how you're going about your programming work. For thhe
quicker you can get up to speed, using the system as intended, the better
shape you'll be in for moving forward.

James

[James Quirk]

Shem,

A couple of weeks have gone by and you've not responded to the message
I sent you: I can't help, if you're not prepared to ask questions. In
this instance, leaving aside the syntactic niceties of AMRITA-programming,
your problem setup is flawed. Specifically, your external-boundary case
is also defining an internal boundary, which is not what you want to do
as the two approaches are conflicting with one another.

All in all, you seem quite confused as to AMRITA's method.
Why would you write:

plotfile /$amrita::cwd/../dens0.ps

when the following would suffice:

plotfile ../dens0.ps

Also, why would you calculate the analytical solution to your problem
outside of the procedure which sets up the problem? You should have
defined it symbolically, inside the setup procedure, in terms of shock
Mach number and solution time; string tokens are not intended for such
purposes. And why would you post-process your results in a nested-loop
outside of the nested-loop that performs the paramter study? You're just
not helping yourself.

Now I could send you my cleaned up script, but with such spoon-feeding
you will never learn to help yourself. If you really want to improve your
AMRITA skills, I will assist you. But there is no point continuing
if there is a two week delay between each and every communication.

You should also feel free to voice your concerns. It generally
pays to swim with AMRITA's flow, but the system is not perfect
and there will be occasions when dropping into fold::{perl,python,ruby}
is the way to go.

James

[Shem]

Sorry about the delay, I've been busy with other things and I neglected to reply. Thank you for following up. I've attached the update file.

The external-boundary case was created with the interior top and bottom wall because I wanted to isolate the effect of the end wall being an external bondary. I've now added another case where the top and bottom wall are also external. For the analytical results, I am not sure how to pass the solution time into the initial problem setup. I have moved the analytical result plotting into its own procedure, is this what you meant? I haven't used to Gnuplot{} environment, because I was unable to find a way to loop through the list of solvers.

Sometimes (with the wedge reflection script), I get a NAN if I march to a certain time, however if I march to an intermediate time, then from there I go to my desired time, there is no problem. Is there a way to predict or get around that? Is it because of the step size?

[James Quirk]

Shem,

> The external-boundary case was created with the interior top and bottom
> wall because I wanted to isolate the effect of the end wall being an
> external bondary. I've now added another case where the top and bottom wall
> are also external. For the analytical results, I am not sure how to pass

That's the case you should have run from the outset, as it
provides the cleanest environment in which to study the end-wall
reflection. But note that with your version of amr_sol
there is no way to deactivate AXS::InternalBoundary once
it has been activated. Therefore to revert to using pure external
boundaries you will need to prescribe a dummy PSI, say -1, which
does not change sign in the computational domain.

> the solution time into the initial problem setup. I have moved the

Try using:

makefield t=$time

> analytical result plotting into its own procedure, is this what you meant?

No. Unlike string tokens, the symbolic expressions defined using ::=
have global scope. So when setting up a test problem, for which you
have an analytic solution, it makes sense for the setup procedure
to define the solution. For it can then be accessed anywhere in
the script. Your script's use of <-> Params:: is not clean
for the <-> operator must be used with care.

> I haven't used to Gnuplot{} environment, because I was unable to find a way
> to loop through the list of solvers.

GnuPlot is a procedure, not an environment. Note there would be no
need to loop through the list of solvers for the results processing
for the processing would be done immediately after the march
command, as in the example below.

>
> Sometimes (with the wedge reflection script), I get a NAN if I march to a
> certain time, however if I march to an intermediate time, then from there I
> go to my desired time, there is no problem. Is there a way to predict or
> get around that? Is it because of the step size?

This sounds suspicious and it is hard to speculate without
a concrete example to dissect.

The usual approach when automating a simulation that might fail
is to wrap the march inside an on::error block, as in:

on::error {
march to t=$time with cfl=$cfl
... process results
}
continue

I see from your script that you have made some effort to follow
the suggestions I made in my earlier message, albeit selectively.
Thus InertShockReflectionProblem is looking closer to the canonical
form, although you've not folded the body of the procedure.
It should really be:

proc InertShockReflectionProblem {
... parameters
}
... body of procedure
end proc

The comment "default parameters" is technically incorrect.
You're providing a parameter list, each of which have default values.
But they are not default parameters, which would imply that
additional parameters might be passed to the procedure
to the ones given.

Also note you have not taken on board my comments regarding the folding
of the pushcwd/popcwd commands. Hence your script does not
flow properly, at least not to a third-party. Please reread
my earlier message.

Are you now using Origami? I suspect not, for your fold-comments
are tautological. Consider the fold "Output initial conditions"
it appears as:

fold::amrita { Output initial conditions
... Output initial density profile image
... Output initial grid
}

whereas all you need is something along the lines of:

fold::amrita { output plots
... density profile
... grid
}

Note this is not knit-picking. The repeated use of
"Output initial" does not buy you anything, and more
importanly does not instill the reader with confidence
that the script is polished. Moreover, the use of:

plotfile ../dens0.ps

suggests that your pushcwd/popcwd pairs are cumbersome.
As a rule of thumb, you should avoid outputting to a parent
directory, and here there is no need for it.

I'm also disappointed to see that you still have
/*amrita::cwd/dens0.ps in your script, see the fold
"Make LaTeX figures." The macro latex::fig uses AMRITA's
search path, which by default looks in CWD, so you
could have got away with &latex::fig([width=...]{dens0.ps}).

The more self-critical you are in constructing your scripts,
today, the better off you will be in the long run. You should
be looking to develop a lean style that is not bogged
down by extraneous details.

Have a stab at refolding your "run simulation" fold.
Give it a couple of attempts, with the results posted here.
Then next week I'll send you my model solution. It's only
by striving to improve your script that you will arrive
at something that will be cost-effective in terms of
building for the future.

James


>
>

[Shem]

In the attached script, I've moved the exact solution in to the setup procedure. I've also switched to using the Gnuplot procedure to make the final plots, rearranged and renamed things to (I hope) flow better and be easier to understand.

I am also wondering if I'm using the isentropic exponent "gamma" the right way. I tried using C'post_shock, for example, but it returns the speed of sound for a gamma=1.4. How would I properly specify a value for this? I also couldn't find out what exactly the sym function does.

Once again, I look forward to your feedback.

[Shem]

...and to add to my previous post, I've attached an example of a script which sometimes fails with a NaN.

First it marches to a time a=5.25 (called a),
from a, it attempts to march to time c=7.15 (called ac),
it fails, but when it marches from a to an intermediate time b=6 (called ab),
and continues from ab to c (called bc), the simulation does not fail.

[Shem]

I am planning to add a script similar to the latest one I've shared as additional material to a publication. The goal is to have the script reproduce the figures in the paper.

I was wondering if you had any advice or suggestions before I do so.

[Shem]

The following is just a re-post of the previous message, without the weird formatting.

[James Quirk]

Shem,

The attached script, 4shem, shows how you can use amrcp
to run an AMRITA script and grab the results when typesetting
a paper. For details, see: amrhelp amrcp. Note the script
is intended to be viewed in amrgi, rather than a linear listing.

James

[Shem]

Thanks for your reply.

I have a few questions about amrcp. Should I be submitting two scripts, the one which runs the simulations, and a second one with the amrcp? I think I've missed the point of it.

I am unsure how to change from the Chp2/my.script to another script. For example,

  amrcp -run another.script -rtn fig1 -> fig

does not work, where another.script (just a copy of my.script) is located in the same directory as 4shem. The fig token is empty.

[j...@amrita-ebook.org]

Shem,

Try dissecting the example below. The first four lines will clone you an example.

The last three lines runs it as if you had created your own example.

James

# cp Chp2/my.script to new example abc/xyc

amrcp -ex Chp2/my.script -rtn SRC -> EX

mkdir abc

execute cp $EX abc/xyz

# now run new example

amrcp -run -ex abc/xyz -rtn fig1 -WORKDIR workdir -> result1

echo $result1

[Shem]

Thank your for the example, it helped me figure out and fix my code.

For anyone else trying this, one problem I had was that if a figure failed to be produced (as occurs in ShockReflArcRamp_NAN.amrita, for example), amrcp would fail in info'checkfiles.

Are there any other outstanding issues that you believe should be addressed?

[j...@amrita-ebook.org]

Shem,

You have the option to use the on::error construct to safeguard against amrcp failing,

see amrhelp on::error .

James