Periodic mesh suggestion

[Hambley, Matthew]

Attached is my first attempt at a periodic mesh.

I found the description of location index sets to be quite hard to read. I think this is at least in part due to the example being incomplete. It looks like it needs bits of the previous 1D example to make sense.

What you should see is a biperiodic 3x3 mesh. An additional set of coordinates are included which describe the position of the wrap-around nodes. A set is then made of these nodes along with the "real" nodes which they represent.

--
Matthew Hambley
Senior Scientific Software Engineer
Met Office Hadley Centre, Exeter, UK

[David Ham]

Hi Matthew,

I can see the vertex locations - which seem correct, as does the periodic topology. 

I can also see the wrap around nodes and the map from wrap-around nodes to topological ("real") nodes, however I can't see how I have enough information to use this.

For example, suppose I wish to calculate the area of face 1. This has nodes 1, 2, 3, 4, but to calculate this area I need to know to use nodes 13, 14, 4, 3. 

(a) how do I (algorithmically) decide that nodes 1 and 2 are supposed to be transformed?

(b) the calculation effectively requires the inverse of the node-equivalence map. However in the case of node 1, the map is not invertible (because both node 13 and node 10 map to node 1).

Regards,

David

--
You received this message because you are subscribed to the Google Groups "UGRID Interoperability" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ugrid-interoperab...@googlegroups.com.
To post to this group, send email to ugrid-inter...@googlegroups.com.
Visit this group at https://groups.google.com/group/ugrid-interoperability.
For more options, visit https://groups.google.com/d/optout.

--

Dr David Ham

Department of Mathematics

Imperial College London

[Hambley, Matthew]

From: David Ham [mailto:da...@ham.dropbear.id.au]

>
> I can see the vertex locations - which seem correct, as does the
> periodic topology.
>
> I can also see the wrap around nodes and the map from wrap-around nodes
> to topological ("real") nodes, however I can't see how I have enough
> information to use this.

After having another look we think you are right. Attached is an amended description file and a diagram of what we think we have described.

We now think this holds all the information you need. In particular you should now be able to calculate the area of any cell. Meanwhile we can still work out the extent of the mesh, which was our original goal.

[David Ham]

Hi all,

I can now believe this works. I believe that the model you are advocating is something like the following:

You store a "broken" periodic topology, which has duplicate vertices but not duplicates of any other entity (edges, faces, 3D cells).

The topology stored refers to the duplicated vertices.

You also store a map from duplicate vertex indices to unique vertex numbers. This enables the periodic topology to be recovered.

Your example has the duplicated vertex numbers last. Is it your intention that this convention forms a part of the specification? The advantage is that you trivially get contiguous numbering of the periodic topology. The potential drawback is that there might be other conventions about the numbering which this might break....

Aside from that query, I think this works.

Regards,

David

[Hambley, Matthew]

From: David Ham [mailto:da...@ham.dropbear.id.au]
>

> I can now believe this works. I believe that the model you are
> advocating is something like the following:
>
> You store a "broken" periodic topology, which has duplicate vertices
> but not duplicates of any other entity (edges, faces, 3D cells).

Yes, it is only the vertices which are duplicated. You could argue that the edges joining duplicate vertices only are also duplicates but we aren't interested in them. Even if you were I think you would dereference the duplicated vertices to get their "real" equivalents and look at the edge there.

> The topology stored refers to the duplicated vertices.
> You also store a map from duplicate vertex indices to unique vertex
> numbers. This enables the periodic topology to be recovered.

Also true. From our point of view UGRID is an "on disc" serialised form of the mesh. We will never use it in this form, rather it will be loaded and converted to an "in memory" representation which we will use.

Part of the conversion process will be to dereference the duplicate vertices and recover the "real" mesh. As you suggest.

> Your example has the duplicated vertex numbers last. Is it your
> intention that this convention forms a part of the specification? The
> advantage is that you trivially get contiguous numbering of the
> periodic topology. The potential drawback is that there might be other
> conventions about the numbering which this might break....

It is shown that way because the example was created by taking a periodic mesh and adding the new vertices to it. I don't think we require it to work that way and wouldn't want to restrict ourselves if a different numbering scheme made mesh generation easier.

[Chris Barker]

On Wed, Feb 22, 2017 at 1:51 AM, Hambley, Matthew <matthew...@metoffice.gov.uk> wrote:

 From our point of view UGRID is an "on disc" serialised form of the mesh. We will never use it in this form, rather it will be loaded and converted to an "in memory" representation which we will use.

This is the intent of UGRID. However, for the most part, for non-periodic meshes, it intentionally maps pretty well to at least some "in memory" representations.

So if it could be extended a bit more to better map a periodic grid to an "typical" in-memory representation, that might be worth  doing.

I've never worked with a periodic mesh, so I have no idea...

-CHB

--

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris....@noaa.gov

[Hambley, Matthew]

From: Chris Barker [mailto:chris....@noaa.gov]

> On Wed, Feb 22, 2017 at 1:51 AM, Hambley, Matthew
> <matthew...@metoffice.gov.uk

> <mailto:matthew...@metoffice.gov.uk> > wrote:
>>
>> From our point of view UGRID is an "on disc" serialised form of
>> the mesh. We will never use it in this form, rather it will be loaded
>> and converted to an "in memory" representation which we will use.
>
> This is the intent of UGRID. However, for the most part, for non-
> periodic meshes, it intentionally maps pretty well to at least some "in
> memory" representations.
>
> So if it could be extended a bit more to better map a periodic grid to
> an "typical" in-memory representation, that might be worth doing.

I understand the desire to have on-disc and in-memory representations
being as similar as possible. The problem we have in our case is that
the additional information we are attempting to convey, the domain
size, is not part of the mesh description itself. Instead it is a
separate but related piece of information inferred from it. We are just
trying to ensure there is enough information in the UGRID file to make
that inference.

We can't simply store it as separate width and height fields as that
would only work for strictly rectangular meshes, which we may not have. Any mesh with ragged edges, a hexagon/pentagon mesh for instance, would fail with simple width and height.

The proposed solution should be general enough to cover all potential
use cases. David Ham's area of the wrap-around cells for instance.

The advantage of the proposed solution is that it does not change any
existing usage. Anyone with a non-periodic mesh will notice no
difference and on-disc and in-memory representations will be quite
alike.

It just makes work for those of us working with periodic meshes and
that is probably just the price we have to pay for doing something
atypical.

Furthermore, even people using periodic meshes don't need to worry
about this issue if they don't care about the width of the wrap-around
cells.

Having written all of the above I can think of an alternative which I
present to the group for consideration.

Instead of an additional special node to hold the notional n+1 location
of the wrap-around node we could mark the wrap-around edge as special
and give it a length.

I think this would allow us to calculate all the properties we could want
of the wrap-around space such as extent and area. However it retains the
number of nodes of the non-periodic version.

--
Matthew Hambley - Dark Lord of the LFRic build system

  Senior Scientific Software Engineer
  Met Office Hadley Centre, Exeter, UK

...I have a ticket for that

[Chris Barker]

I THINK this is the current status:

Someone (Matthew Hambley) has proposed a way to represent periodic grids (or at least some subset of them) in UGRID.

At least one other person (David Ham) has reviewed it and think it looks OK.

The proposal adds stuff to UGRID, but does not change or break anything already in there.

I have looked it over, but don't use periodic models, so don't feel qualified to say anything beyond what I've already said.

David and Matthew, are you working independently? i.e with different models? It would nice to have some confirmation that the approach is useful beyond one model.

But barring any objections, It woudl be great if someone could add this to the spec doc and do a PR on the repo:

https://github.com/ugrid-conventions/ugrid-conventions

-CHB

On Fri, Feb 24, 2017 at 5:56 AM, Hambley, Matthew <matthew...@metoffice.gov.uk> wrote:

From: Chris Barker [mailto:chris....@noaa.gov]

> On Wed, Feb 22, 2017 at 1:51 AM, Hambley, Matthew

> <matthew.hambley@metoffice.gov.uk

[David Ham]

Hi All,

I can confirm that I don't directly work with Matthew (although I do have some links with the Met Office via the Gung Ho project). 

I don't directly use UGrid because Firedrake, the platform whose development I lead, is a finite element project and UGrid doesn't support the range of discretisations we need. However I can confirm that periodic meshes are very widely used, particularly among those people who develop and test ocean and atmosphere models. Periodic meshes provide mechanisms for constructing unbounded domains in finite space and can be easier to construct test cases on than sphere meshes. UGrid does need a way to do this if it is to span all the reasonable use cases.

Regards,

David

On Mon, 27 Feb 2017 at 14:50 Chris Barker <chris....@noaa.gov> wrote:

I THINK this is the current status:

Someone (Matthew Hambley) has proposed a way to represent periodic grids (or at least some subset of them) in UGRID.

At least one other person (David Ham) has reviewed it and think it looks OK.

The proposal adds stuff to UGRID, but does not change or break anything already in there.

I have looked it over, but don't use periodic models, so don't feel qualified to say anything beyond what I've already said.

David and Matthew, are you working independently? i.e with different models? It would nice to have some confirmation that the approach is useful beyond one model.

But barring any objections, It woudl be great if someone could add this to the spec doc and do a PR on the repo:

https://github.com/ugrid-conventions/ugrid-conventions

-CHB

On Fri, Feb 24, 2017 at 5:56 AM, Hambley, Matthew <matthew...@metoffice.gov.uk> wrote:

From: Chris Barker [mailto:chris....@noaa.gov]

> On Wed, Feb 22, 2017 at 1:51 AM, Hambley, Matthew

> <matthew...@metoffice.gov.uk

--

--

You received this message because you are subscribed to the Google Groups "UGRID Interoperability" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ugrid-interoperab...@googlegroups.com.
To post to this group, send email to ugrid-inter...@googlegroups.com.
Visit this group at https://groups.google.com/group/ugrid-interoperability.
For more options, visit https://groups.google.com/d/optout.

[Chris Barker]

On Tue, Feb 28, 2017 at 1:24 PM, David Ham <da...@ham.dropbear.id.au> wrote:

I can confirm that I don't directly work with Matthew (although I do have some links with the Met Office via the Gung Ho project). 

I"m not worried about who works with whom -- we're all friends here :-)

It would jstu be nice to know that more than one use-case is being considered -- we don't want to standardize on something that works great for one model/grid, but doesn't work well for any others

I don't directly use UGrid because Firedrake, the platform whose development I lead, is a finite element project and UGrid doesn't support the range of discretizations we need.

I'd like to hear more about that -- UGRID certainly supports many FE models -- what doesn't it support in your case?

 

However I can confirm that periodic meshes are very widely used, particularly among those people who develop and test ocean and atmosphere models. Periodic meshes provide mechanisms for constructing unbounded domains in finite space and can be easier to construct test cases on than sphere meshes. UGrid does need a way to do this if it is to span all the reasonable use cases.

I don't think anyone has said otherwise -- the only question I have is whether the proposal on the table is flexible enough for many (most) use cases. I have no way to judge that, and it seems most of teh other folks on this list are similarly clueless :-)

-CHB

 

Regards,

David

On Mon, 27 Feb 2017 at 14:50 Chris Barker <chris....@noaa.gov> wrote:

I THINK this is the current status:

Someone (Matthew Hambley) has proposed a way to represent periodic grids (or at least some subset of them) in UGRID.

At least one other person (David Ham) has reviewed it and think it looks OK.

The proposal adds stuff to UGRID, but does not change or break anything already in there.

I have looked it over, but don't use periodic models, so don't feel qualified to say anything beyond what I've already said.

David and Matthew, are you working independently? i.e with different models? It would nice to have some confirmation that the approach is useful beyond one model.

But barring any objections, It woudl be great if someone could add this to the spec doc and do a PR on the repo:

https://github.com/ugrid-conventions/ugrid-conventions

-CHB

On Fri, Feb 24, 2017 at 5:56 AM, Hambley, Matthew <matthew.hambley@metoffice.gov.uk> wrote:

From: Chris Barker [mailto:chris....@noaa.gov]

> On Wed, Feb 22, 2017 at 1:51 AM, Hambley, Matthew

> <matthew.hambley@metoffice.gov.uk

--

--

To unsubscribe from this group and stop receiving emails from it, send an email to ugrid-interoperability+unsub...@googlegroups.com.
To post to this group, send email to ugrid-interoperability@googlegroups.com.

Visit this group at https://groups.google.com/group/ugrid-interoperability.
For more options, visit https://groups.google.com/d/optout.

--

Dr David Ham

Department of Mathematics

Imperial College London

[Hambley, Matthew]

From: Chris Barker [mailto:chris....@noaa.gov]

[snip]

> I don't think anyone has said otherwise -- the only question I have is
> whether the proposal on the table is flexible enough for many (most)
> use cases. I have no way to judge that, and it seems most of teh other
> folks on this list are similarly clueless :-)

This may have become lost but there are, in fact, two proposals on the
table.

Initially I suggested having additional vertices at the "right hand" edge
which are topologically the same vertices as the "left hand" edge but are
geographically different.

I got the impression that this was causing some people distress as it
makes the on-disc representation rather different from the in-memory one.
In particular there are these additional vertices on disc which do not
exist in memory.

In light of this I suggested an alternative where the wrap-around edges
have length data on them. This should mean that a periodic mesh looks
exactly as it does now but with enough data to reason about the wrap around
region.

The first suggestion is easiest to deal with since you actually have
co-ordinates for the wrap-around vertices, making reasoning easy.
Unfortunately it does lightly mangle the existing representation.

The second suggestion is harder to deal with, requiring trigonometry to
synthesise the co-ordinates, but leaves the original file intact.

--
Matthew Hambley