Add ability to specify LINE_COORD_CODE for line devices

[johodges]

Is your feature request related to a problem? Please describe. I am working on adding contour plotting functionality to the python version of dataplot. FDS does not currently output the full xyz coordinate location of each point in a line device (only outputs the axis which is varying). Dataplot needs this information to build the meshgrid of points for comparison.

Describe the solution you'd like Add a new DEVC namelist input LINE_COORD_CODE which will overwrite the auto generation of this variable in read.f90 (~line 13460). This would allow the user to set the value to 123 to request all 3 coordinate outputs. It looks like DUMP already supports this LINE_COORD_CODE.

Describe alternatives you've considered We could hard-code a naming convention in dataplot to grab this information from headers, or parse the FDS file to grab this information. That does not seem like as good a solution to me.

Additional context I can add the functionality if the team is ok with this addition.

[rmcdermo]

What if, instead of POINTS=..., we have POINTS_ARRAY={Nx,Ny,Nz} or something like this? I think we have talked about this before in terms of minimizing the number of DEVC lines in the input file. My recollection is that now you need a separate DEVC line for each line of POINTS, right?

@mcgratta Thoughts?

[johodges]

That's correct. We are currently using one DEVC point array per vertical slice in the contour. In my current python script I am extracting the x-coordinate from the column name and concatenating all the points into a single array to pass to meshgrid. Allowing the user to specify POINTS_ARRAY would be a cleaner solution overall but would require a bit more re-write in read and dump.

McCaffrey_22kW_50mm.txt

[mcgratta]

I'll see what it would take to generalized POINTS to an ARRAY.

[mcgratta]

I've looked into this issue, and I think the best solution is to take Randy's suggestion of POINTS_ARRAY and for each create a separate file, i.e. CHID_array_N.something which is formatted like this

Nx Ny Nz
(X(I), I=1,Nx)
(Y(J), J=1,Ny)
(Z(K), K=1,Nz)
(((Q(I,J,K), I=1,Nx, J=1,Ny, K=1,Nz)

This could be text or binary, but it wouldn't be a typical comma-delimited thing. That is, you'd have to parse it with something. I suppose it could be formatted like a csv, but I think no matter what you do you're going to have to parse it with something other than Excel or similar. Maybe we should use a VTK compatible format?

[rmcdermo]

Hmmm... if we have to parse it with something other than a CSV reader, then we might as well just use a SLCF and parse that with Jonathan's pyfdstools.

I suggest we punt and just use POINTS with several DEVC lines.

[mcgratta]

If we limit to 2-D, you could have a .csv file with a matrix of values. But that is close to what Jonathan has now. Also, there are some QUANTITY's that cannot be output via SLCF. Also, SLCF doesn't do time-averaging directly.

[johodges]

I was thinking a flattened array of points rather than outputting a structured grid within the file. If the implementation issue is with what data format to use, something like the attached would work. Here there are four columns with x,y,z and quantity with NX x NY x NZ rows. Users would need to do some manual manipulation if you want a structured output to visualize, but it would work fine for the implementation I was planning in dataplot.

I am open to leveraging either VTK or binary reads of slice data if we want to go that direction. It will not be as clean on the version control, especially if we want to output multiple time steps to do time averaging.

McCaffrey_22kW_50mm_line_manual_edit.csv

Edit: which now that I think about it is what Kevin was suggesting anyway. I am planning on having dataplot pass contour data to a meshgrid call so we would not need a separate parser. A simple CSV read would work with the flattened array.

[rmcdermo]

@johodges Good point about version control. That is something that has definitely hindered use of SLCF for validation output. Likewise, really for any binary format. I personally do not think we want an additional parser to be necessary. I think it is important that this output is read by dataplot (@mcgratta we mean the new python version of dataplot, which @johodges has modified [yet to push up] to handle these contour plots).

[johodges]

The McCaffrey script is currently a separate file rather than running through dataplot so that I can manually structure the data. I was waiting to do the PR until we decided how to handle the POINTS output so that I could merge it into the validation config file and the dataplot plumbing. Do you want me to get it merged in with the current implementation or hold off until we finalize this discussion?

[rmcdermo]

Let's hold off until the points array stuff is settled. Thanks