MAST-U wall outline should have a traceable source

[jacklovell]

At the moment, cherab.mastu.machine.MASTU_WALL_OUTLINE is a hard-coded array of values, with no indication of where these have come from or what date range they are valid for. The array is similar (but not necessarily identical) to "wall outlines" I've seen in other MAST-U codes.

It would be better to take this sort of information from an "official" source instead (e.g. UDA). However, UDA doesn't currently seem to have an exact analogue of this outline in the machine description. The closest seems to be /limiter/efit, but that differs in a couple of respects:

• It cuts off a corner between T5 and the baffle
• In the main chamber, the outer extent of the outline is at R=1.521m, rather than 2.0m.

I'm a bit worried that these differences are significant enough to break existing users' codes. There are a couple of alternatives that I can think of:

1. Use /passive/efit instead of /limiter/efit, and extract coordinates from the relevant passive structures to match as closely as possible the existing outline. This seems like a lot of extra complexity.
2. Ask for the cherab.mastu wall outline to be included in the machine description too. However, that risks having unnecessary duplication in the machine description: which of the two outlines should other users of UDA use?
3. Document in the code where the wall outline actually came from (as long as the source is stored properly, e.g. in Sharepoint), but leave it hard-coded in Cherab.

Of these alternatives, I personally prefer option 3. Overall, it's a toss-up between using /limiter/efit or option 3 for me.

Thoughts?

[CnlPepper]

Option 4) ask the efit people to use a more accurate limiter. I believe it doesn't need to be convex anymore.

I would query the EFIT limiter tbh.

[jacklovell]

So the consensus from Alex and I discussing this with Lucy is that we should actually do something more along the lines of option 2). Have a more accurate outline - possibly called something like /limiter/optical - in the machine description which is intended for more general use than /limiter/efit. It seems having multiple limiters for different applications is a better idea than I realised.

@mattngc How did you obtain the MASTU_WALL_OUTLINE array in the first place? If we can reproduce that (and include some extra detail like the coil cases) we can simply produce a netCDF file containing the data and get Lucy to upload that to the UDA server for general availability.

[mattngc]

Hey, I received this wall outline from James, I believe he made it himself for constructing camera meshes. So the provenance of this outline is already rather sketchy. On the otherhand, this is not a primary piece of engineering data. It is a secondary reduced representation of engineering data. We couldn't expect a 2D profile to accurately represent something that is fundamentally 3D in structure. I think the best thing to do is make any necessary corrections to outline and put it on the UDA server. This isn't really a CHERAB issue.

[jacklovell]

That's fair enough. But knowing the method used to produce the outline would then give a better understanding of the limitations (e.g. is it a single toroidal slice of the 3D CAD, a folded minimum surface or some sort of average first wall?). I'm with you on putting it on UDA, and documenting the method used to produce it on the MAST-U machine description pages.

In this case, cherab.mastu.machine should provide a way of reading this from the machine description.

[jacklovell]

Just spoken to James Harrison about this. MASTU_WALL_OUTLINE likely came from a FIESTA boundary, but the evolution of tile design means this may not be current. We would still need to work out how this boundary is produced for FIESTA.

Alternatively, we can produce our own optical boundary in Cherab itself using the following method: fire rays originating from several points in the vessel, where at each point we fire rays radially with a distribution of poloidal angles, and record the hit points of each ray. This then builds up an array of points in the poloidal plane on the surfaces.

Some post-processing of this data would be required: we'd need to check that the corners of structures are resolved correctly, that all sides of objects such as coil cans are included, and we'd likely need to split the resulting array of points to account for different objects (e.g. tile surfaces vs coil cans). We'd also want to clean up the arrays so that we only store the minimum number of points necessary to describe the shape: matplotlib.Path could probably help here.

The benefit of this method is that we could quickly build up 'optical limiting surfaces' at multiple toroidal locations. Depending on how much manual cleanup is required, we could provide this path at each of the 12 sectors for example.