Carlos, I am starting a new thread for this as the old
one is getting a bit longer and off the original topic.
Re: your email:
>Yeah, I have the changed the ReactiveEulerEquations.amr. I haven't made
>any modifications since you last looked at it, but it may be a good idea
>to cut the induction zone Q term out of the equation set now
Yes, as I first stab I would keep it simple. You will have to modify
the
specific ReactiveEulerEquations.amr I sent in a similar way you did
before.
>I think a good place to start would be to modify the ComputeZndProfile
>procedure.
Actually, this is probably the last piece of the jigsaw to consider -
all ComputeZNDprofile
is really needed for is to set up special initial conditions - it is
not worth
getting this right if we can't get the BCG/ReactiveEulerEquations
working
in the first place - other simple initial conditions can be used to
test this such as a top-hat
pressure profile (the standard 'direct ignition' startup).
I suggest starting by looking at the different files in the cloned bcg
directory
folder I sent and look at what would need to be changed in going from
the
3step to the 2step model.
I have modified the ReactiveEulerEquations.amr file and dealt away
with the Qi term, and now I simply have a Q term associated with the
second mass fraction.
My first question involves the SourceTerms.amr file. In this file I
modified P, T, DfDt and DyDt. My DfDt and DyDt read something like:
DfDt = -Ki*EXP(-E/T)
DyDt = -Ke*(1-y)**(ETA)
For our model of interest, would it be necessary to include a
switch? , for example:
If WW(5) < 1, then DfDt = as above
else DfDt = 0
If WW(5) < 1, then DyDt = 0
else DyDt = as above
My second question is about the Startup.amr file. I've noticed a
parameter, NU that's listed twice:
WRITE(AMR::LOGFILE(),*) 'NU = ',NU
WRITE(AMR::LOGFILE(),*) 'NU = ',NU
Is there any need for this to be listed twice or is it an extra line
that can be deleted?
Thanks,
Carlos
On Jul 2, 4:13 am, Gary Sharpe <men...@leeds.ac.uk> wrote:
> Carlos, I am starting a new thread for this as the old
> one is getting a bit longer and off the original topic.
> Re: your email:
> >Yeah, I have the changed the ReactiveEulerEquations.amr. I haven't made
> >any modifications since you last looked at it, but it may be a good idea
> >to cut the induction zone Q term out of the equation set now
> Yes, as I first stab I would keep it simple. You will have to modify
> the
> specific ReactiveEulerEquations.amr I sent in a similar way you did
> before.
> >I think a good place to start would be to modify the ComputeZndProfile
> >procedure.
> Actually, this is probably the last piece of the jigsaw to consider -
> all ComputeZNDprofile
> is really needed for is to set up special initial conditions - it is
> not worth
> getting this right if we can't get the BCG/ReactiveEulerEquations
> working
> in the first place - other simple initial conditions can be used to
> test this such as a top-hat
> pressure profile (the standard 'direct ignition' startup).
> I suggest starting by looking at the different files in the cloned bcg
> directory
> folder I sent and look at what would need to be changed in going from
> the
> 3step to the 2step model.
Thanks, I will look at the data next week -Eric ---
Eric C. Marineau, Ph.D.
Postdoctoral Scholar in Aeronautics T5 Hypervelocity Shock Tunnel
California Institute of Technology MC 105-50
1200 East California Blvd Pasadena CA 91125 (626) 395-8311 Fax: (626) 449-2677
-----Original Message-----
From: Carlos <cleun...@uottawa.ca>
Date: Wed, 2 Jul 2008 13:06:01 To: amrita-ebook<amrita-ebook@googlegroups.com>
Subject: Re: Changing reaction rate model
Gary,
I have modified the ReactiveEulerEquations.amr file and dealt away
with the Qi term, and now I simply have a Q term associated with the
second mass fraction.
My first question involves the SourceTerms.amr file. In this file I
modified P, T, DfDt and DyDt. My DfDt and DyDt read something like:
DfDt = -Ki*EXP(-E/T)
DyDt = -Ke*(1-y)**(ETA)
For our model of interest, would it be necessary to include a
switch? , for example:
If WW(5) < 1, then DfDt = as above
else DfDt = 0
If WW(5) < 1, then DyDt = 0
else DyDt = as above
My second question is about the Startup.amr file. I've noticed a
parameter, NU that's listed twice:
WRITE(AMR::LOGFILE(),*) 'NU = ',NU
WRITE(AMR::LOGFILE(),*) 'NU = ',NU
Is there any need for this to be listed twice or is it an extra line
that can be deleted?
Thanks,
Carlos
On Jul 2, 4:13 am, Gary Sharpe <men...@leeds.ac.uk> wrote:
> Carlos, I am starting a new thread for this as the old
> one is getting a bit longer and off the original topic.
> Re: your email:
> >Yeah, I have the changed the ReactiveEulerEquations.amr. I haven't made
> >any modifications since you last looked at it, but it may be a good idea
> >to cut the induction zone Q term out of the equation set now
> Yes, as I first stab I would keep it simple. You will have to modify
> the
> specific ReactiveEulerEquations.amr I sent in a similar way you did
> before.
> >I think a good place to start would be to modify the ComputeZndProfile
> >procedure.
> Actually, this is probably the last piece of the jigsaw to consider -
> all ComputeZNDprofile
> is really needed for is to set up special initial conditions - it is
> not worth
> getting this right if we can't get the BCG/ReactiveEulerEquations
> working
> in the first place - other simple initial conditions can be used to
> test this such as a top-hat
> pressure profile (the standard 'direct ignition' startup).
> I suggest starting by looking at the different files in the cloned bcg
> directory
> folder I sent and look at what would need to be changed in going from
> the
> 3step to the 2step model.
> My first question involves the SourceTerms.amr file. In this file I
> modified P, T, DfDt and DyDt. My DfDt and DyDt read something like:
> DfDt = -Ki*EXP(-E/T)
> DyDt = -Ke*(1-y)**(ETA)
> For our model of interest, would it be necessary to include a
> switch? , for example:
> If WW(5) < 1, then DfDt = as above
> else DfDt = 0
> If WW(5) < 1, then DyDt = 0
> else DyDt = as above
Looking at it, it should be something like
IF (f.GE.1.D0) THEN
DfDt=0.0
DyDt=...as above
ELSE
DfDt=...as above
DyDt=0.0
ENDIF
Note it appears to be doing a simple
two step integration so you will
have to do the same again, but
this time based on the half time
step value fs.
Note also keeping the activation
pressure Pact in is important to
prevent reaction in the initial quiescent
state.
Also, take care to get the expression
for T correct.
> My second question is about the Startup.amr file. I've noticed a
> parameter, NU that's listed twice:
> WRITE(AMR::LOGFILE(),*) 'NU = ',NU
> WRITE(AMR::LOGFILE(),*) 'NU = ',NU
> Is there any need for this to be listed twice or is it an extra line
> that can be deleted?
Yes, this looks like an duplication.
However, it isn't too important as
this just writes to a logfile.
> On Jul 2, 4:13 am, Gary Sharpe <men...@leeds.ac.uk> wrote:
> > Carlos, I am starting a new thread for this as the old
> > one is getting a bit longer and off the original topic.
> > Re: your email:
> > >Yeah, I have the changed the ReactiveEulerEquations.amr. I haven't made
> > >any modifications since you last looked at it, but it may be a good idea
> > >to cut the induction zone Q term out of the equation set now
> > Yes, as I first stab I would keep it simple. You will have to modify
> > the
> > specific ReactiveEulerEquations.amr I sent in a similar way you did
> > before.
> > >I think a good place to start would be to modify the ComputeZndProfile
> > >procedure.
> > Actually, this is probably the last piece of the jigsaw to consider -
> > all ComputeZNDprofile
> > is really needed for is to set up special initial conditions - it is
> > not worth
> > getting this right if we can't get the BCG/ReactiveEulerEquations
> > working
> > in the first place - other simple initial conditions can be used to
> > test this such as a top-hat
> > pressure profile (the standard 'direct ignition' startup).
> > I suggest starting by looking at the different files in the cloned bcg
> > directory
> > folder I sent and look at what would need to be changed in going from
> > the
> > 3step to the 2step model.
That is for both progress variables going from 0 to 1, right? If I set
it up in a similar way as the 3cb model (f goes from 1 to 0, y goes
from 0 to 1), it should be something like
IF (f.LE.0.D0) THEN
DfDt = 0
DyDt = Ke*(1-y)**(ETA)
ELSE
DfDt = -Ki*EXP(-E/T)
DyDt = 0
END IF
ie. LE 0 instead of GE 1
On Jul 3, 11:46 am, Gary Sharpe <men...@leeds.ac.uk> wrote:
> > My first question involves the SourceTerms.amr file. In this file I
> > modified P, T, DfDt and DyDt. My DfDt and DyDt read something like:
> > DfDt = -Ki*EXP(-E/T)
> > DyDt = -Ke*(1-y)**(ETA)
> > For our model of interest, would it be necessary to include a
> > switch? , for example:
> > If WW(5) < 1, then DfDt = as above
> > else DfDt = 0
> > If WW(5) < 1, then DyDt = 0
> > else DyDt = as above
> Looking at it, it should be something like
> IF (f.GE.1.D0) THEN
> DfDt=0.0
> DyDt=...as above
> ELSE
> DfDt=...as above
> DyDt=0.0
> ENDIF
> Note it appears to be doing a simple
> two step integration so you will
> have to do the same again, but
> this time based on the half time
> step value fs.
> Note also keeping the activation
> pressure Pact in is important to
> prevent reaction in the initial quiescent
> state.
> Also, take care to get the expression
> for T correct.
> > My second question is about the Startup.amr file. I've noticed a
> > parameter, NU that's listed twice:
> > WRITE(AMR::LOGFILE(),*) 'NU = ',NU
> > WRITE(AMR::LOGFILE(),*) 'NU = ',NU
> > Is there any need for this to be listed twice or is it an extra line
> > that can be deleted?
> Yes, this looks like an duplication.
> However, it isn't too important as
> this just writes to a logfile.
> Gary.
> > Thanks,
> > Carlos
> > On Jul 2, 4:13 am, Gary Sharpe <men...@leeds.ac.uk> wrote:
> > > Carlos, I am starting a new thread for this as the old
> > > one is getting a bit longer and off the original topic.
> > > Re: your email:
> > > >Yeah, I have the changed the ReactiveEulerEquations.amr. I haven't made
> > > >any modifications since you last looked at it, but it may be a good idea
> > > >to cut the induction zone Q term out of the equation set now
> > > Yes, as I first stab I would keep it simple. You will have to modify
> > > the
> > > specific ReactiveEulerEquations.amr I sent in a similar way you did
> > > before.
> > > >I think a good place to start would be to modify the ComputeZndProfile
> > > >procedure.
> > > Actually, this is probably the last piece of the jigsaw to consider -
> > > all ComputeZNDprofile
> > > is really needed for is to set up special initial conditions - it is
> > > not worth
> > > getting this right if we can't get the BCG/ReactiveEulerEquations
> > > working
> > > in the first place - other simple initial conditions can be used to
> > > test this such as a top-hat
> > > pressure profile (the standard 'direct ignition' startup).
> > > I suggest starting by looking at the different files in the cloned bcg
> > > directory
> > > folder I sent and look at what would need to be changed in going from
> > > the
> > > 3step to the 2step model.
I've gone back and ran the old pulsate file using the 3cb model, but
the simulation seems to get stuck when it tries to march in time, even
after changing the node spacing and letting it run for a whole day. It
seems to be able to build the znd code and the solver code fine. I
simply took one part of the code and modified it to look like:
plugin amr_sol
utilize 2step::Machinery
ReactiveEulerEquations {
space = 1D
model = 3cb
}
I was wondering whether I didn't implement the model properly, or
whether the 3cb model is really that much more expensive than the 1a
model
On Jul 3, 2:40 pm, Carlos <cleun...@uottawa.ca> wrote:
> That is for both progress variables going from 0 to 1, right? If I set
> it up in a similar way as the 3cb model (f goes from 1 to 0, y goes
> from 0 to 1), it should be something like
> IF (f.LE.0.D0) THEN
> DfDt = 0
> DyDt = Ke*(1-y)**(ETA)
> ELSE
> DfDt = -Ki*EXP(-E/T)
> DyDt = 0
> END IF
> ie. LE 0 instead of GE 1
> On Jul 3, 11:46 am, Gary Sharpe <men...@leeds.ac.uk> wrote:
> > > My first question involves the SourceTerms.amr file. In this file I
> > > modified P, T, DfDt and DyDt. My DfDt and DyDt read something like:
> > > DfDt = -Ki*EXP(-E/T)
> > > DyDt = -Ke*(1-y)**(ETA)
> > > For our model of interest, would it be necessary to include a
> > > switch? , for example:
> > > If WW(5) < 1, then DfDt = as above
> > > else DfDt = 0
> > > If WW(5) < 1, then DyDt = 0
> > > else DyDt = as above
> > Note it appears to be doing a simple
> > two step integration so you will
> > have to do the same again, but
> > this time based on the half time
> > step value fs.
> > Note also keeping the activation
> > pressure Pact in is important to
> > prevent reaction in the initial quiescent
> > state.
> > Also, take care to get the expression
> > for T correct.
> > > My second question is about the Startup.amr file. I've noticed a
> > > parameter, NU that's listed twice:
> > > WRITE(AMR::LOGFILE(),*) 'NU = ',NU
> > > WRITE(AMR::LOGFILE(),*) 'NU = ',NU
> > > Is there any need for this to be listed twice or is it an extra line
> > > that can be deleted?
> > Yes, this looks like an duplication.
> > However, it isn't too important as
> > this just writes to a logfile.
> > Gary.
> > > Thanks,
> > > Carlos
> > > On Jul 2, 4:13 am, Gary Sharpe <men...@leeds.ac.uk> wrote:
> > > > Carlos, I am starting a new thread for this as the old
> > > > one is getting a bit longer and off the original topic.
> > > > Re: your email:
> > > > >Yeah, I have the changed the ReactiveEulerEquations.amr. I haven't made
> > > > >any modifications since you last looked at it, but it may be a good idea
> > > > >to cut the induction zone Q term out of the equation set now
> > > > Yes, as I first stab I would keep it simple. You will have to modify
> > > > the
> > > > specific ReactiveEulerEquations.amr I sent in a similar way you did
> > > > before.
> > > > >I think a good place to start would be to modify the ComputeZndProfile
> > > > >procedure.
> > > > Actually, this is probably the last piece of the jigsaw to consider -
> > > > all ComputeZNDprofile
> > > > is really needed for is to set up special initial conditions - it is
> > > > not worth
> > > > getting this right if we can't get the BCG/ReactiveEulerEquations
> > > > working
> > > > in the first place - other simple initial conditions can be used to
> > > > test this such as a top-hat
> > > > pressure profile (the standard 'direct ignition' startup).
> > > > I suggest starting by looking at the different files in the cloned bcg
> > > > directory
> > > > folder I sent and look at what would need to be changed in going from
> > > > the
> > > > 3step to the 2step model.
> I've gone back and ran the old pulsate file using the 3cb model, but > the simulation seems to get stuck when it tries to march in time, even > after changing the node spacing and letting it run for a whole day. It > seems to be able to build the znd code and the solver code fine. I > simply took one part of the code and modified it to look like:
> plugin amr_sol > utilize 2step::Machinery > ReactiveEulerEquations { > space = 1D > model = 3cb > }
> I was wondering whether I didn't implement the model properly, or > whether the 3cb model is really that much more expensive than the 1a > model
There is clearly a problem with your implementation. Post a mailit and I'll take a look at it.
When I try to make the mailit, I get the same problem. The process freezes and the mailit can't get created. I've attached my script.
In the directory where the script is contained, I have the sub-directory /3step/Machinery, where the cloned solver/znd/equation set files are stored, as well as a AmritaUtilize.amr
>> I've gone back and ran the old pulsate file using the 3cb model, but >> the simulation seems to get stuck when it tries to march in time, even >> after changing the node spacing and letting it run for a whole day. It >> seems to be able to build the znd code and the solver code fine. I >> simply took one part of the code and modified it to look like:
>> plugin amr_sol >> utilize 2step::Machinery >> ReactiveEulerEquations { >> space = 1D >> model = 3cb >> }
>> I was wondering whether I didn't implement the model properly, or >> whether the 3cb model is really that much more expensive than the 1a >> model
> There is clearly a problem with your implementation. > Post a mailit and I'll take a look at it.
On Sun, 6 Jul 2008, cleun...@uottawa.ca wrote: > When I try to make the mailit, I get the same problem. The process freezes > and the mailit can't get created. I've attached my script.
You could have made a mailit of your directory tree without actually running the script. That way I'd have a complete record of what you're doing.
> In the directory where the script is contained, I have the sub-directory > /3step/Machinery, where the cloned solver/znd/equation set files are > stored, as well as a AmritaUtilize.amr
AMRITA is a system that helps those who help themselves. Here you've sent me your driver script but the details I need to look at are in 3step/Machinery directory and the AmritaUtilize.amr procedure, both of which are missing.
Have another go. But this time, copy all the relevant file to a directory xyz, preserving whatever directory structure you're using then run:
amrita -mailit xyz
You could simply run amrita -mailit on the directory tree where you're working, but that would pack binary files as well as text files and so, depending on what you've done, may result in a file that is too big to mail.
> >> I've gone back and ran the old pulsate file using the 3cb model, but > >> the simulation seems to get stuck when it tries to march in time, even > >> after changing the node spacing and letting it run for a whole day. It > >> seems to be able to build the znd code and the solver code fine. I > >> simply took one part of the code and modified it to look like:
> >> I was wondering whether I didn't implement the model properly, or > >> whether the 3cb model is really that much more expensive than the 1a > >> model
> > There is clearly a problem with your implementation. > > Post a mailit and I'll take a look at it.
Carlos,
I am a bit surprised you are ready to run the script already.
Have you modified all the files already then? I was hoping you were
going to
post each one in turn here, so we could discuss (and if necessary,
iterate) them - so that there would be a record for the next person.
Have you already re-done the ComputeZNDwave file too?
If so have you plotted out what your initiation actually gives
using the along command for P, RHO, U, Zi, Ze
- i.e. after setting up the ZND wave on the grid but
BEFORE trying to march - this may illuminate whether
something is wrong?
Gary
On Jul 4, 8:10 pm, Carlos <cleun...@uottawa.ca> wrote:
> I've gone back and ran the old pulsate file using the 3cb model, but
> the simulation seems to get stuck when it tries to march in time, even
> after changing the node spacing and letting it run for a whole day. It
> seems to be able to build the znd code and the solver code fine. I
> simply took one part of the code and modified it to look like:
> plugin amr_sol
> utilize 2step::Machinery
> ReactiveEulerEquations {
> space = 1D
> model = 3cb
> }
> I was wondering whether I didn't implement the model properly, or
> whether the 3cb model is really that much more expensive than the 1a
> model
> On Jul 3, 2:40 pm, Carlos <cleun...@uottawa.ca> wrote:
> > That is for both progress variables going from 0 to 1, right? If I set
> > it up in a similar way as the 3cb model (f goes from 1 to 0, y goes
> > from 0 to 1), it should be something like
> > IF (f.LE.0.D0) THEN
> > DfDt = 0
> > DyDt = Ke*(1-y)**(ETA)
> > ELSE
> > DfDt = -Ki*EXP(-E/T)
> > DyDt = 0
> > END IF
> > ie. LE 0 instead of GE 1
> > On Jul 3, 11:46 am, Gary Sharpe <men...@leeds.ac.uk> wrote:
> > > > My first question involves the SourceTerms.amr file. In this file I
> > > > modified P, T, DfDt and DyDt. My DfDt and DyDt read something like:
> > > > DfDt = -Ki*EXP(-E/T)
> > > > DyDt = -Ke*(1-y)**(ETA)
> > > > For our model of interest, would it be necessary to include a
> > > > switch? , for example:
> > > > If WW(5) < 1, then DfDt = as above
> > > > else DfDt = 0
> > > > If WW(5) < 1, then DyDt = 0
> > > > else DyDt = as above
> > > Note it appears to be doing a simple
> > > two step integration so you will
> > > have to do the same again, but
> > > this time based on the half time
> > > step value fs.
> > > Note also keeping the activation
> > > pressure Pact in is important to
> > > prevent reaction in the initial quiescent
> > > state.
> > > Also, take care to get the expression
> > > for T correct.
> > > > My second question is about the Startup.amr file. I've noticed a
> > > > parameter, NU that's listed twice:
> > > > WRITE(AMR::LOGFILE(),*) 'NU = ',NU
> > > > WRITE(AMR::LOGFILE(),*) 'NU = ',NU
> > > > Is there any need for this to be listed twice or is it an extra line
&
