Support Custom FW Definitions #198
Conversation
| toroidal_angles = [] | ||
|
|
||
| for line in data[start_line - 1 :]: | ||
| if line.count("\t") == 2: |
There was a problem hiding this comment.
searching for tabs makes me nervous.... does T1E have a standard format/reader for these files? Is there a rigid structure we can rely upon?
There was a problem hiding this comment.
There is some structure, I got the code snippet that writes the files from Bonita today and it specifically uses '\t' as a delimiter. I could make the delimiter character a variable perhaps. Or we could leave it up to users to have their own function that reads their data. The class I have created to make custom FW takes a set of points defining ribs as an input so as to make it function with any sort of first wall definition that can be represented with ribs.
There was a problem hiding this comment.
It may use tabs, that's fine, but I expect that the structure is defined by the order in which certain lines appear and the data expected to be on each line.
There was a problem hiding this comment.
If I reverse engineer what you wrote, I'm guessing the format is:
num_toroidal_angles num_poloidal_angles periods
# repeat for each toroidal angle
toroidal_angle
### repeat for each poloidal angle
r z
If so, then you can write a parser that
- Reads the first line to get those three values
- For loop over num toroidal angles
- read toroidal angle
- Initialize
profile - For loop over poloidal angles
- Read
r&z - Convert to
x,y,z - Append to
profile
- Read
- Append to
profiles
parastell/utils.py
Outdated
| return x_data, y_data, z_data, grid_points | ||
|
|
||
|
|
||
| class KisslingerSurface(object): |
There was a problem hiding this comment.
Should this be in IVB somewhere as a variation on the current surface definition to allow us to use them more interchangeably? I haven't really thought about the details, but assumed that's how this would come together, similar to what you've done with magnet definitions
The approach I have taken is to create a class that has the same methods and behavior as those that we use from VMECData.
In this case, the custom first wall is defined in R-Z coordinates in a manner similar to how we define ribs. By assuming that the points on each rib are spaced evenly in the poloidal direction, a continuous surface which is a function of poloidal and toroidal angle can be created by interpolation of those points.
I was thinking we could set something up where there is a base class for representing the innermost surface, call it ReferenceSurface() or something along those lines, then we could have two classes that inherit from it, one that works with VMEC data and one that works with R-Z data, and by doing so we could have some infrastructure set up to possibly extend to other formats if it becomes necessary.
For right now I just added a vmec2xyz() method to my new KisslingerSurface() class that allows this class to be slotted in in place of a VMECData() object as a demonstration. I've included custom_geometry_example.py for a bit of context.
Addresses #108