In a problem of a propagating wave, I am interested in superposing the
wave front at different times on the same image. For example, say I
have the solutions at times t1, t2 and t3. I want to plot first the
solution at t3, than overlay the solution at t2 extending partly over
t3, but not all the way to the front. Then overlay the solution at
t1, and so on. The end plot would be a sequence of the wave fronts.
Ahead of each wave front, i would have sufficient white space to avoid
visual clutter and confusion.
Right now, I call the same plotting procedure iteratively using the
stored solutions at different times, within the same plotfile block.
I use
plot image {G1} m<myfavoritefield[]>
instead of
plot image {G} m<myfavoritefield[]>
in the plotting procedures in order to avoid plotting the entire base
grid. However, this workaround is not very elegant, and does not give
sufficient white space demarcation ahead of the wave until the t-1
solution.
Any ideas of a better strategy? Perhaps I can add white rectangles to
make better controlled demarcations. I could plot these interposed
between the successive timesolutions.
James, this is like what i had (manually) last year for the APS poster
with the overlay of the schlieren snap shots and the soot foil.
> In a problem of a propagating wave, I am interested in superposing the > wave front at different times on the same image. For example, say I > have the solutions at times t1, t2 and t3. I want to plot first the > solution at t3, than overlay the solution at t2 extending partly over > t3, but not all the way to the front. Then overlay the solution at > t1, and so on. The end plot would be a sequence of the wave fronts. > Ahead of each wave front, i would have sufficient white space to avoid > visual clutter and confusion.
> Right now, I call the same plotting procedure iteratively using the > stored solutions at different times, within the same plotfile block. > I use > plot image {G1} m<myfavoritefield[]> > instead of > plot image {G} m<myfavoritefield[]> > in the plotting procedures in order to avoid plotting the entire base > grid. However, this workaround is not very elegant, and does not give > sufficient white space demarcation ahead of the wave until the t-1 > solution. > Any ideas of a better strategy? Perhaps I can add white rectangles to > make better controlled demarcations. I could plot these interposed > between the successive timesolutions.
> James, this is like what i had (manually) last year for the APS poster > with the overlay of the schlieren snap shots and the soot foil.
You should use the plotarea command to fix the active drawing area on the page, see:
amrhelp plotarea
and you'll need to activate clipping with:
clipping on
Have a stab at it, and if you get stuck I'll help you further.
Yes, thanks. I see where to go with this. It's essentially what I
was doing by hand last year using adobe illustrator to clip the
various profiles over a desired area.
However, I have to automate it, so the bounds of the plotarea need to
change dynamically with the position of the shock. Is there a
procedure to find the location of the leading shock already build in?
On Nov 14, 9:34 pm, James Quirk <j...@galcit.caltech.edu> wrote:
> > In a problem of a propagating wave, I am interested in superposing the
> > wave front at different times on the same image. For example, say I
> > have the solutions at times t1, t2 and t3. I want to plot first the
> > solution at t3, than overlay the solution at t2 extending partly over
> > t3, but not all the way to the front. Then overlay the solution at
> > t1, and so on. The end plot would be a sequence of the wave fronts.
> > Ahead of each wave front, i would have sufficient white space to avoid
> > visual clutter and confusion.
> > Right now, I call the same plotting procedure iteratively using the
> > stored solutions at different times, within the same plotfile block.
> > I use
> > plot image {G1} m<myfavoritefield[]>
> > instead of
> > plot image {G} m<myfavoritefield[]>
> > in the plotting procedures in order to avoid plotting the entire base
> > grid. However, this workaround is not very elegant, and does not give
> > sufficient white space demarcation ahead of the wave until the t-1
> > solution.
> > Any ideas of a better strategy? Perhaps I can add white rectangles to
> > make better controlled demarcations. I could plot these interposed
> > between the successive timesolutions.
> > James, this is like what i had (manually) last year for the APS poster
> > with the overlay of the schlieren snap shots and the soot foil.
> You should use the plotarea command to fix the active drawing
> area on the page, see:
> amrhelp plotarea
> and you'll need to activate clipping with:
> clipping on
> Have a stab at it, and if you get stuck I'll
> help you further.
> Yes, thanks. I see where to go with this. It's essentially what I
> was doing by hand last year using adobe illustrator to clip the
> various profiles over a desired area.
> However, I have to automate it, so the bounds of the plotarea need to
> change dynamically with the position of the shock. Is there a
> procedure to find the location of the leading shock already build in?
You can use the along command. Suppose you have a wave moving
from left to right then you would use something along the lines of:
> On Nov 14, 9:34 pm, James Quirk <j...@galcit.caltech.edu> wrote:
> > Matei,
> > On Fri, 14 Nov 2008, matei wrote:
> > > In a problem of a propagating wave, I am interested in superposing the
> > > wave front at different times on the same image. For example, say I
> > > have the solutions at times t1, t2 and t3. I want to plot first the
> > > solution at t3, than overlay the solution at t2 extending partly over
> > > t3, but not all the way to the front. Then overlay the solution at
> > > t1, and so on. The end plot would be a sequence of the wave fronts.
> > > Ahead of each wave front, i would have sufficient white space to avoid
> > > visual clutter and confusion.
> > > Right now, I call the same plotting procedure iteratively using the
> > > stored solutions at different times, within the same plotfile block.
> > > I use
> > > plot image {G1} m<myfavoritefield[]>
> > > instead of
> > > plot image {G} m<myfavoritefield[]>
> > > in the plotting procedures in order to avoid plotting the entire base
> > > grid. However, this workaround is not very elegant, and does not give
> > > sufficient white space demarcation ahead of the wave until the t-1
> > > solution.
> > > Any ideas of a better strategy? Perhaps I can add white rectangles to
> > > make better controlled demarcations. I could plot these interposed
> > > between the successive timesolutions.
> > > James, this is like what i had (manually) last year for the APS poster
> > > with the overlay of the schlieren snap shots and the soot foil.
> > You should use the plotarea command to fix the active drawing
> > area on the page, see:
> > amrhelp plotarea
> > and you'll need to activate clipping with:
> > clipping on
> > Have a stab at it, and if you get stuck I'll
> > help you further.
> > Yes, thanks. I see where to go with this. It's essentially what I
> > was doing by hand last year using adobe illustrator to clip the
> > various profiles over a desired area.
> > However, I have to automate it, so the bounds of the plotarea need to
> > change dynamically with the position of the shock. Is there a
> > procedure to find the location of the leading shock already build in?
> You can use the along command. Suppose you have a wave moving
> from left to right then you would use something along the lines of:
> along y=$ymid locate last P[]>$Ptol -> Xfront
> James
> > On Nov 14, 9:34 pm, James Quirk <j...@galcit.caltech.edu> wrote:
> > > Matei,
> > > On Fri, 14 Nov 2008, matei wrote:
> > > > In a problem of a propagating wave, I am interested in superposing the
> > > > wave front at different times on the same image. For example, say I
> > > > have the solutions at times t1, t2 and t3. I want to plot first the
> > > > solution at t3, than overlay the solution at t2 extending partly over
> > > > t3, but not all the way to the front. Then overlay the solution at
> > > > t1, and so on. The end plot would be a sequence of the wave fronts.
> > > > Ahead of each wave front, i would have sufficient white space to avoid
> > > > visual clutter and confusion.
> > > > Right now, I call the same plotting procedure iteratively using the
> > > > stored solutions at different times, within the same plotfile block.
> > > > I use
> > > > plot image {G1} m<myfavoritefield[]>
> > > > instead of
> > > > plot image {G} m<myfavoritefield[]>
> > > > in the plotting procedures in order to avoid plotting the entire base
> > > > grid. However, this workaround is not very elegant, and does not give
> > > > sufficient white space demarcation ahead of the wave until the t-1
> > > > solution.
> > > > Any ideas of a better strategy? Perhaps I can add white rectangles to
> > > > make better controlled demarcations. I could plot these interposed
> > > > between the successive timesolutions.
> > > > James, this is like what i had (manually) last year for the APS poster
> > > > with the overlay of the schlieren snap shots and the soot foil.
> > > You should use the plotarea command to fix the active drawing
> > > area on the page, see:
> > > amrhelp plotarea
> > > and you'll need to activate clipping with:
> > > clipping on
> > > Have a stab at it, and if you get stuck I'll
> > > help you further.
> Yes, thanks. I see where to go with this. It's essentially what I
> was doing by hand last year using adobe illustrator to clip the
> various profiles over a desired area.
> However, I have to automate it, so the bounds of the plotarea need to
> change dynamically with the position of the shock. Is there a
> procedure to find the location of the leading shock already build in?
> On Nov 14, 9:34 pm, James Quirk <j...@galcit.caltech.edu> wrote:
> > Matei,
> > On Fri, 14 Nov 2008, matei wrote:
> > > In a problem of a propagating wave, I am interested in superposing the
> > > wave front at different times on the same image. For example, say I
> > > have the solutions at times t1, t2 and t3. I want to plot first the
> > > solution at t3, than overlay the solution at t2 extending partly over
> > > t3, but not all the way to the front. Then overlay the solution at
> > > t1, and so on. The end plot would be a sequence of the wave fronts.
> > > Ahead of each wave front, i would have sufficient white space to avoid
> > > visual clutter and confusion.
> > > Right now, I call the same plotting procedure iteratively using the
> > > stored solutions at different times, within the same plotfile block.
> > > I use
> > > plot image {G1} m<myfavoritefield[]>
> > > instead of
> > > plot image {G} m<myfavoritefield[]>
> > > in the plotting procedures in order to avoid plotting the entire base
> > > grid. However, this workaround is not very elegant, and does not give
> > > sufficient white space demarcation ahead of the wave until the t-1
> > > solution.
> > > Any ideas of a better strategy? Perhaps I can add white rectangles to
> > > make better controlled demarcations. I could plot these interposed
> > > between the successive timesolutions.
> > > James, this is like what i had (manually) last year for the APS poster
> > > with the overlay of the schlieren snap shots and the soot foil.
> > You should use the plotarea command to fix the active drawing
> > area on the page, see:
> > amrhelp plotarea
> > and you'll need to activate clipping with:
> > clipping on
> > Have a stab at it, and if you get stuck I'll
> > help you further.
Ok, Brian and I got it to work. The following part of script plots
the overlays. Note the difficulty due to the fact that plotarea
requires dimensions in mm on the page, different from the grid
coordinates.
---
set Ptol=1.1
proc MateiRed
RGB<255,0,0>
end proc
plotfile ps/density/densityend.ps
PlotDomain fcolour = m<1.0> , bcolour = MateiRed
bbox in mm -> xmm1,ymm1,xmm2,ymm2
bbox -> x1,y1,x2,y2
set mmscale #= $ymm2/ $y2
do m=48,1,-5
flowin io/default/Pulse$m
echo $m
along y=10 locate last P[]>$Ptol -> Xfront
set plotx1 #= ($Xfront-30)*$mmscale + $xmm1
set plotwidth #= 40*$mmscale
plotarea $plotx1, $ymm1,$plotwidth,$ymm2
clipping on
DensityPlot
end do
clipping off
DrawCylinderBody <- ParamSet::
plotfile
---
> Ok, Brian and I got it to work. The following part of script plots
> the overlays. Note the difficulty due to the fact that plotarea
> requires dimensions in mm on the page, different from the grid
> coordinates.
It would be fairly straightforward to take what you've
done and package it in a procedure so that all the
scaling machinations are hidden away, and then you'd
end up with something that could be used transparently
by third parties.
On Mon, 17 Nov 2008, Matei Radulescu wrote: > james, > I can post something like that shortly, although I'm not a 100% > comfortable with passing variables and commands to call other > procedures. Do I pass those as strings? For example, I want to pass > the PlotDensity command to the procedure, so that it calls PlotDensity > from within the procedure. Let me clean it up a little and give it a > shot. > matei
There's more than one way it could be done. But as a first step, I would suggest you try something very simple and not even bother to pass the drawing commands to the procedure. For instance, you could use:
PlotWholeChannel do n=1,$n flowin io/soln$n FocusOnFront DensityPlot end do
Have a stab at it and I'll answer any specific questions you might have.
> Have a stab at it and I'll answer any specific questions you might
I stabbed it. There are two procedures that need to be called back
to back, as in your example:
--
fold::amrita{ PlotWholeChannel
proc PlotWholeChannel
PlotDomain fcolour = m<1.0>
bbox in mm -> xmm1,ymm1,xmm2,ymm2
bbox -> x1,y1,x2,y2
set ScaleParam::mmscale #= $ymm2/ $y2
set ScaleParam::xmm1 #= $xmm1
set ScaleParam::xmm2 #= $xmm2
set ScaleParam::ymm1 #= $ymm1
set ScaleParam::ymm2 #= $ymm2
end proc
}
fold::amrita{ PlotFront
proc PlotFront{
pc = SchlierenImage #Plot Command
ys = 0 #y-line along which to determine
leading shock location
Ptol = 1.1 #value of P used as threhhold to
find the shock
Xback = 5 #extent of the window to the back of
shock
Xfront = 5 #extent of the plot window to the
front of the shock
mmscale = 1 #scale parameters
xmm1 = 1
xmm2 = 1
ymm1 = 1
ymm2 = 1
} <-ScaleParam::
along y=$ys locate last P[]>$Ptol -> Xshock
set plotx1 #= ($Xshock-$Xback)*$mmscale + $xmm1
set plotwidth #= ($Xback+$Xfront)*$mmscale
plotarea $plotx1, $ymm1,$plotwidth,$ymm2
clipping on
$pc
end proc
}
plotfile ps/myplot.ps
PlotWholeChannel
do n = 1, $n
flowin io/model$n
PlotFront{
pc =DensityPlot
Xback=10
}
end do
clipping off
plotfile
> James,
> > Have a stab at it and I'll answer any specific questions you might
> I stabbed it. There are two procedures that need to be called back
> to back, as in your example:
> --
> fold::amrita{ PlotWholeChannel
> proc PlotWholeChannel
> PlotDomain fcolour = m<1.0>
> bbox in mm -> xmm1,ymm1,xmm2,ymm2
> bbox -> x1,y1,x2,y2
> set ScaleParam::mmscale #= $ymm2/ $y2
> set ScaleParam::xmm1 #= $xmm1
> set ScaleParam::xmm2 #= $xmm2
> set ScaleParam::ymm1 #= $ymm1
> set ScaleParam::ymm2 #= $ymm2
> end proc
> }
> fold::amrita{ PlotFront
> proc PlotFront{
> pc = SchlierenImage #Plot Command
> ys = 0 #y-line along which to determine
> leading shock location
> Ptol = 1.1 #value of P used as threhhold to
> find the shock
> Xback = 5 #extent of the window to the back of
> shock
> Xfront = 5 #extent of the plot window to the
> front of the shock
> mmscale = 1 #scale parameters
> xmm1 = 1
> xmm2 = 1
> ymm1 = 1
> ymm2 = 1
> } <-ScaleParam::
> along y=$ys locate last P[]>$Ptol -> Xshock
> set plotx1 #= ($Xshock-$Xback)*$mmscale + $xmm1
> set plotwidth #= ($Xback+$Xfront)*$mmscale
> plotarea $plotx1, $ymm1,$plotwidth,$ymm2
> clipping on
> $pc
> end proc
> }
> plotfile ps/myplot.ps
> PlotWholeChannel
> do n = 1, $n
> flowin io/model$n
> PlotFront{
> pc =DensityPlot
> Xback=10
> }
> end do
> clipping off
> plotfile
I would move the clipping off command to
the PlotFront procedure so that you have:
clipping on
$pc
clipping off
so that the clipping commands are balanced
at the point of use. I would also replace $pc by
James,
Here are the updated procedures with your recommendations. Thanks for
your help. They are working nicely.
fold::amrita{ PlotWholeChannel
proc PlotWholeChannel
PlotDomain fcolour = m<1.0>
bbox in mm -> xmm1,ymm1,xmm2,ymm2
bbox -> x1,y1,x2,y2
set ScaleParam::mmscale #= $ymm2/ $y2
set ScaleParam::xmm1 #= $xmm1
set ScaleParam::xmm2 #= $xmm2
set ScaleParam::ymm1 #= $ymm1
set ScaleParam::ymm2 #= $ymm2
end proc
}
fold::amrita{ PlotFront
proc PlotFront{
pc = SchlierenImage #Plot Command
ys = 0 #y-line along which to determine
leading shock location
Ptol = 1.1 #value of P used as threhhold to
find the shock
Xback = 5 #extent of the window to the back of
shock
Xfront = 5 #extent of the plot window to the
front of the shock
mmscale = 1 #scale parameters
xmm1 = 1
xmm2 = 1
ymm1 = 1
ymm2 = 1
} <-ScaleParam::
along y=$ys locate last P[]>$Ptol -> Xshock
set plotx1 #= ($Xshock-$Xback)*$mmscale + $xmm1
set plotwidth #= ($Xback+$Xfront)*$mmscale
plotarea $plotx1, $ymm1,$plotwidth,$ymm2
clipping on
parse <token> pc
clipping off
end proc
}
plotfile ps/density_evolution.ps
PlotWholeChannel
do n = 1, $n
flowin io/model$n
PlotFront{
ys = 59.99
Xback = 60
Xfront = 20
fold::param'pc {
DensityPlot
plot Z[] contour L0.9 rgb<1,0,0>
}
}
end do
plotfile
> James, > Here are the updated procedures with your recommendations. Thanks for > your help. They are working nicely.
There's one last step you could do. If you employ Amrita's utilize command your new procedures can be squirreled away and then accessed using something along the lines of:
utilize mateis::utils ... PlotWholeDomain
This would allow you to build up your own extensions that could be used from student to student.
> > James,
> > Here are the updated procedures with your recommendations. Thanks for
> > your help. They are working nicely.
> There's one last step you could do. If you employ
> Amrita's utilize command your new procedures can be
> squirreled away and then accessed using something
> along the lines of:
> utilize mateis::utils
> ...
> PlotWholeDomain
> This would allow you to build up your own extensions
> that could be used from student to student.
[mir] That's a good idea. I guess this is short from putting them
directly on the Amrita path where it looks for the *.amr procedures,
right?
> > There's one last step you could do. If you employ > > Amrita's utilize command your new procedures can be > > squirreled away and then accessed using something > > along the lines of:
|
