Variable angle of reslope

[jlwoodr]

Adding variable angle of reslope 'variAOR'.

[krober10nd]

Thanks @jlwoodr . I just renamed the new field to something a bit more easy to remember. We're trying to consistently follow snake case in new developments.

[WPringle]

I think Line 655 should be obj.variable_angle_of_reslope instead of just variable_angle_of_reslope

[WPringle]

also, instead of doing two different inputs we could just have one (angle_of_reslope) and it just accepts either a scalar or a vector

[krober10nd]

also, instead of doing two different inputs we could just have one (angle_of_reslope) and it just accepts either a scalar or a vector

yea that's a good idea.

[krober10nd]

Okay, now they're one field. If the field angle_of_reslope has a length greater than one, then it uses each value otherwise it's assumed to be a scalar with a value of 60 degrees (which was previously the scalar default).

I haven't tested it yet. Lets see the example @jlwoodr presents.

[WPringle]

Ok, yeah let's test it. Should be a cell or vector? (implemented as cell now)

[krober10nd]

Yea, thought the same. I was thinking a cell as perhaps you could add variable angle of reslope along the width of a particular channel too for even more control.

[WPringle]

I see, do you mean the length of a channel? Like so have a cell entry that is a vector for each point of the channel?

[krober10nd]

I see, do you mean the length of a channel? Like so have a cell entry that is a vector for each point of the channel?

Yes, this is what I mean.

[WPringle]

Ok that seems reasonable then. Yeah just try it out with various scalar and cell inputs to make sure all the various usage cases works.

[CHLNDDEV]

@jlwoodr do you want to modify this to support instead a variable ch parameter?

[jlwoodr]

I am not sure yet. From what I have seen in my example, users are unlikely to see much change in channel refinement when playing only with angle_of_reslope unless extreme values are used. So maybe we should have variable 'ch' parameter? Can we just do both variable angle_of_reslope and 'ch'? I think ideally a user would have a channel width for each point along a thalweg. Then OM2D would simply place however many elements the user specifies across that width.

[jlwoodr]

After running a few more tests, I think it is necessary to have variable 'ch' if users want to change mesh resolution based on channel width. From what I have seen (at least on this relatively small test domain) 'angle_of_reslope' has very little if any noticeable effect. I will start working on a variable 'ch' soon.

[krober10nd]

When you say "channel width" you mean an underwater/submerged formation? I think this is one aspect that is often confused. The "channel" mesh size function was originally intended to densify mesh resolution nearby thalwegs under the assumption that these features were responsible for more flux into the estuary and thus would benefit from capturing more finely.

There was some sensitivity to the tides to this mesh resolution heuristic, which was studied in one of our articles but as it remains to date, the benefit still largely remains qualitative and not easily quantifiable.

If the channel is described by the banks of the water feature, the feature size mesh sizing function already enables the user to specify the number of elements across the width of the channel.

[jlwoodr]

Keith,

Sorry for my delayed response to this. When I say "channel width" I do mean underwater formation. I have been using the "fs" parameter to control how many elements across the width. I guess I am just running into issues with visibly adjusting resolution around the different channels. Maybe it is my untrained eye, but it appears that there is no difference between the 1000 m wide channel and 2000 m. I wonder if I am just not using deep enough channels? These are extremely wide compared to their depth.

Johnathan

On Mon, Dec 28, 2020 at 2:38 PM Keith Roberts notifications@github.com wrote:

When you say "channel width" you mean an underwater formation? Because if the channel is described by the banks of the water feature, the feature size sizing function enables the user to specify the number of elements across the width of the channel.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/CHLNDDEV/OceanMesh2D/pull/162#issuecomment-751840088, or unsubscribe https://github.com/notifications/unsubscribe-auth/AMEHHOMLQPSJBASZ7Q5K7RDSXDNBXANCNFSM4VEMOFSQ .

[krober10nd]

When I say "channel width" I do mean underwater formation. I have been using the "fs" parameter to control how many elements across the width.

If you want to resolve an underwater channel the fs parameter will not handle that. The fs or feature size is for measuring the distance of the shoreline features and dividing this distance by a constant r to get a local mesh resolution. The shoreline width uses the passed shoreline vector(s) to estimate its width.

[krober10nd]

@jlwoodr do you intend to continue this or would you like me to close it?

[jlwoodr]

Keith,

Sorry about the late response on this, totally slipped my mind. I will likely have to pick this back up in a few months so it is cool if you close it.

Johnathan

On Thu, Apr 8, 2021 at 7:20 PM Keith Roberts @.***> wrote:

@jlwoodr https://github.com/jlwoodr do you intend to continue this or would you like me to close it?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/CHLNDDEV/OceanMesh2D/pull/162#issuecomment-816296066, or unsubscribe https://github.com/notifications/unsubscribe-auth/AMEHHOKQULDZXDYGA3FAWCLTHY22ZANCNFSM4VEMOFSQ .

[krober10nd]

No worries. I'll close this for now. Let me know when you're back into this! Cheers.