'selective' grid refinement levels

[chris]

We have control over grid refinement in the sense that once the
refinement ratio and the maximum number of grid layers have been set,
'setflags' is used to manually specify which cells should be refined.

However, my understanding is this is an all-or-nothing proposition: if
a flag is set, the message is 'go as deep as you need to'. Otherwise,
'don't touch anything...'

Is there a way to tweak that behavior? I'm thinking of something along
the lines of: Set the refinement ratio to 2 everywhere. 'setflags'
using a uniform criterion where refinement will be required (or
whatever is needed, this is the go/no-go part). BUT THEN say 'give me
up to 5 grid levels here, but no more than 2 there...'

Some thoughts:
...I do appreciate that geographically tweaking a criterion threshold
could come close to accomplishing the same thing. It's just a
===lot=== more pain to tweak that, and serves a different purpose
anyway: I see the threshold as a limit to capture flow details. Given
that I do want to capture a detail, the maximum grid level is a
measure of how much detail I want in a given area... two different
things. My understanding is that the current implementation assumes
that I want the same level of detail everywhere.

And if it looks like a recipe for disaster (garbage in, garbage
out...), I just happen to have a problem where features coming out of
a 6-level region would travel to 3 and 0-level regions without
reflecting back in the 6-level area... with huge computational
savings...

Thanks
Chris

[James Quirk]

Chris,

On Thu, 10 Jun 2010, chris wrote:

> We have control over grid refinement in the sense that once the
> refinement ratio and the maximum number of grid layers have been set,
> 'setflags' is used to manually specify which cells should be refined.
>
> However, my understanding is this is an all-or-nothing proposition: if
> a flag is set, the message is 'go as deep as you need to'. Otherwise,
> 'don't touch anything...'

You can qualify a setflags with a gridlist to restrict its operation.
For instance:

setflags [ooo|oxo|ooo] P[]>$Ptol {G0}

would restrict the operation to the base grid, while:

setflags [ooo|oxo|ooo] P[]>$Ptol {g1}

would restricts the operation to the second finest grid.
Note G_l is determined from the flags on G_{l-1} so it
would make no sense to use:

setflags [ooo|oxo|ooo] P[]>$Ptol {g0}

>
> Is there a way to tweak that behavior? I'm thinking of something along
> the lines of: Set the refinement ratio to 2 everywhere. 'setflags'
> using a uniform criterion where refinement will be required (or
> whatever is needed, this is the go/no-go part). BUT THEN say 'give me
> up to 5 grid levels here, but no more than 2 there...

You could do this using the clearflags command:

setflags [ooo|oxo|ooo] P[]>$Ptol {G0-G4}
clearflags [ooo|oxo|ooo] HERE[] {G2-G4}

where you've defined HERE to be some function that describes the
region where you don't need the full resolution e.g.:

HERE ::= (X[]>$x1) && (X[]<$x2) && (Y[]>$y1) && (Y[]<$y2)

Of course you could also use:

setflags [ooo|oxo|ooo] P[]>$Ptol {G0}
setflags [ooo|oxo|ooo] P[]>$Ptol && !HERE[] {G1-G4}

>
> Some thoughts:
> ...I do appreciate that geographically tweaking a criterion threshold
> could come close to accomplishing the same thing. It's just a
> ===lot=== more pain to tweak that, and serves a different purpose
> anyway: I see the threshold as a limit to capture flow details. Given
> that I do want to capture a detail, the maximum grid level is a
> measure of how much detail I want in a given area... two different
> things. My understanding is that the current implementation assumes
> that I want the same level of detail everywhere.

Yes, and no. If you use the refinement criteria as above then
different regions will have different numbers of grid levels.

>
> And if it looks like a recipe for disaster (garbage in, garbage
> out...), I just happen to have a problem where features coming out of
> a 6-level region would travel to 3 and 0-level regions without
> reflecting back in the 6-level area... with huge computational
> savings...

For robustness, you want to miminize the chance of a strong
shock crossing a fine-coarse boundary. But the idioms are
set up to allow you to do what you think is right for the
problem in hand.

James
>
> Thanks
> Chris
>
>

[Christian Hébert]

WHOAHHH!!!!   Sweet...

I admit, I thought I was going fishing there...
(didn't see that in the doc. I looked in the wrong place?)

...just saved me about 20h of CPU time/run...
Thanks!
Chris

----- On 2010-06-10 2:03 PM, James Quirk wrote: -----

[James Quirk]

Chris,

On Thu, 10 Jun 2010, Christian H�bert wrote:

> WHOAHHH!!!!�� Sweet...
>
> I admit, I thought I was going fishing there...
> (didn't see that in the doc. I looked in the wrong place?)

AMR_SOL's idioms where chosen to reflect patterns of work
which make sense. I don't claim they cover all the bases,
and so should you want something that is not implemented
it's still worth your while speaking up. For if the
pattern makes sense, I'll consider adding it in.

James

> --
> 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.
> To unsubscribe from this group, send email to amrita-ebook...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/amrita-ebook?hl=en.
>
>