Closed AreWeDreaming closed 2 years ago
Looking at the source, it looks like the validity information comes from the \\BCI::TOP.STAT...
MDS+ node, and the data from \\BCI::TOP.DEN...
. So the problem originates in the raw data stored in MDS+. Is this an isolated case, or this is true for all DIII-D shots? I think you'll have to ask the responsible officer for the interferometer diagnostic...
I checked 166508
and 187313
they show the exact same situation. I'll try to get the attention of a diagnostician.
I assumed that STAT
and DEN
had the same time basis, but my assumption was probably not correct !?
Can you try to do a dim_of()
on the \\BCI::TOP.STAT...
? This may clear out the issue.
Yeah, these do not have the same time bases at all.
TDIs['time'] = f"dim_of({TDIs['R0']})"
TDIs['time_valid'] = f"dim_of({TDIs['R0_validity']})"
data = mdsvalue('d3d', 'BCI', pulse, TDIs).raw()
print(data['time']-data['time_valid'][1:])
>> [1.3175049 1.3175049 1.3175049 ... 1.3173828 1.3173828 1.3173828]
I guess we either interpolate (weird) or remove the entire ods[f'interferometer.channel.{k}.n_e_line.validity_timed']
entry from the mapping.
nearest
interpolation should be appropriate
Addressed in #182
Thank you! I have cherry-picked the commits relevant to the interferometer fixes in master
When testing the DIII-D mapping for the interferometry I noticed that the time is incorrectly in milliseconds instead of seconds. This is addressed in d3d_fix_interferometer_mapping. However, there is another problem: When loading #170325 I noticed that,
n_e_line.time
andn_e_line.data
have 8995 entries.n_e_line.validity_timed
has 8996 entries but should have the same dimensions as the other two. I do not know how to resolve this myself. Suggestions?