Grid adaption on curved surface

[chris]

I have a curvilinear grid geometry with a curved surface in it
(circular). The flow currently shows artefacts on the wall due to the
N-sided nature of the surface. I could use a very fine mesh structure
for that wall but ideally, for the mesh adaption process, the elements
on the curved wall would need to be fitted to the exact computed wall
instead of an N-sided polygon.

There is a reference to this problem in James' thesis (shock
reflection by a cylinder, section 6.2.1, 2nd paragraph), so it
evidently has been done at some point. But I haven't found any
reference/example into the actual mechanics of doing so.

Assuming it can in fact still be done:
Is this a simple callback overload in amr_sol (much like patch
mapping), or is it significantly more involved?
Is there an example somewhere I might have missed? (instead of
reinventing the wheel, I always start with an example...)
Thanks!

[Matei Radulescu]

Christian,
I have used the embedded boundary technique to represent the surface of
a cylinder in problems of interaction with shocks or detonation waves.
It behaved well and permitted to use a rectangular grid. If you want to
go that route, there are examples posted on the AMRITA e-book about how
this is done; I can also forward a working script.
matei

--

You received this message because you are subscribed to the Google
Groups "amrita-ebook" group.
To post to this group, send email to amrita...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/amrita-ebook?hl=.

[James Quirk]

Chris,

AMR_SOL's body-fitted machinery is not actively supported,
mainly for the reasons you've run into which are quite hard
to solve and package for general use. The alternative,
which works well for stylized shapes, like your cylinder,
is to employ a level-set approach that allows internal
boundaries to be specified. This is not covered in
the VKI notes, but two examples that illustrate the approach are:

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

The second of these I've cleaned up into the attached,
run_lithotripsy_new, to show how I would write the
script today. If you take a look where the BoundaryConditions
are defined you'll see a call to a routine AXS::InternalBoundary.
This routine takes a symbolic expression PSI which defines
a distance function for the geometry of interest i.e. for a point
(x,y) PSI gives the distance to the closest wall.

Give the above a try then if you have any questions as to
how the AXS method works, give me a shout.

James

[chris]

Thanks for the input guys:

Matei: I always welcome working scripts... I'm thinking I might have
to give it a try. This would give me a starting point.

James: I understand the mechanics of the PSI way, but there's a
>>major<< snag: it doesn't work. The good new is I know why: Defining
a PSI function on a regular grid works fine, but I still need to
actively map my patches to physical boundaries, ie. the grid is
stretched/shrinked to fit my boundaries. Whenever I'm calling a slab
of fortran to do that, it seems to defeat the PSI machinery. It
runs... without any boundary...

I've been wrestling with this since your last post. I finally found
this minutes ago by taking your own script and sending the grid to a
fortran double-loop that recreates the regular rectangular grid --> No
go... Commenting out the 'grid code/rectgrid' call --> works fine.
(And yes, the grid is identical in both cases)

Too bad, would have been an easy way to get there... Let me know if
you think of something that might be done to make it work.
Thanks

>  run_lithotripsy_new
> 8KViewDownload

[James Quirk]

Chris,

>
> James: I understand the mechanics of the PSI way, but there's a
> >>major<< snag: it doesn't work. The good new is I know why: Defining
> a PSI function on a regular grid works fine, but I still need to
> actively map my patches to physical boundaries, ie. the grid is
> stretched/shrinked to fit my boundaries. Whenever I'm calling a slab
> of fortran to do that, it seems to defeat the PSI machinery. It
> runs... without any boundary...

The level-set approach is not meant to be used with a body-fitted
grid. Unfortunately, as you have found, there is no error check
to inform the end-user. I've made a mental note to add one.

>
> I've been wrestling with this since your last post. I finally found
> this minutes ago by taking your own script and sending the grid to a
> fortran double-loop that recreates the regular rectangular grid --> No
> go... Commenting out the 'grid code/rectgrid' call --> works fine.
> (And yes, the grid is identical in both cases)
>
> Too bad, would have been an easy way to get there... Let me know if
> you think of something that might be done to make it work.

Without seeing your geometry, it's hard to comment. But as the level-set
approach is just a distance function, there is no intrinsic reason why it
couldn't cope with your set up. There are, however, a few gotchas to be
aware of. For instance, the method fails on a thin plate: owing to the
way the flow reflection is handled, the upper-surface interferes with the
lower-surface, and vice versa. Anyhow, if you post your geometry, I'll
take a look at it and let you know if the approach is suitable or not.

James

[Christian Hébert]

Well... I was trying to avoid doing it this way but I guess it's really the best thing to do. I believe it means that the positional accuracy of my boundaries is no longer a function of the initial problem but of the refinement scheme (ie, a boundary will fall on the closest cell, the size of the latter being a function of the refinement level). That's what I was trying to avoid, but I was surprised to see that raising 'r' just a bit goes a long way: without refining too much, I can get the error down to 0.002"... I stopped caring a long time before that point...

This brings up a small issue though: Through test problems, I discovered that the PSI function must really be defined as a NEGATIVE distance function. Positive is inside a solid to its surface, negative is in the flow to the boundary. Can you confirm this? I need to mix and match a bunch of these through min/max functions and the sign is a crucial issue in that context.
Chris

----- On 2009-11-25 4:34 PM, James Quirk wrote: -----

[James Quirk]

Chris,

> This brings up a small issue though: Through test problems, I discovered
> that the PSI function must really be defined as a NEGATIVE distance
> function. Positive is inside a solid to its surface, negative is in the
> flow to the boundary. Can you confirm this? I need to mix and match a
> bunch of these through min/max functions and the sign is a crucial issue
> in that context.

You are correct. The AXS sign convention is PSI[]>0 inside a body and
PSI[]<0 outside. I'm not sure why Aslam-Xu-Stewart chose to do it that
way, but they did. Note if you take a look inside:

$AMRITA/plugin/amr_sol/stdlib/AXS/InternalBoundary.amr

you'll see that the boundary condition is essentially a user-supplied
piece of code which just happens to be bundled with AMRITA. Thus is
can be used as a template to add other boundary conditions, say
a transipration model like the one recently requested by Matei.

James