Fixing bug in IDL DLM RadarYMDHMSGetSite

[egthomas]

This pull request fixes a bug in the IDL DLM implementation of RadarYMDHMSGetSite which prevents the correct status value being returned from the hdw file.

Currently, the status field returned by RadarYMDHMSGetSite will always be zero, whereas on this branch the correct value will be returned (ie 1 for active or -1 for inactive). As far as I can tell this bug has been present since the new hdw file format was introduced in RST 4.7. Oops.

[ecbland]

@egthomas This works if the radar was active on the requested date (i.e. I get status=1 on this branch, status=0 on develop).

But if the input date is outside the range that the radar was operating, site=RadarYMDHMSGetSite(___) returns zero (not a structure). So I can never get site.status=-1 from that function. Is that the intended behaviour here?

[egthomas]

@ecbland thanks for testing this! Do you mind giving a specific example of the date and radar combinations you tried?

I think you are encountering the expected behavior - my understanding is that a status = -1 means the radar was previously operating but is now decommissioned / offline. If a date is supplied before the first valid line in the hdw.dat file, then the radar did not exist yet and there is no hardware information / status flag to return, hence the zero and not a structure. However, if the code is never returning a structure with status = -1 then that may be a problem (and possibly due to some combination of the end dates in the hdw.dat and radar.dat files).

[ecbland]

Sorry @egthomas for the slow response...for some reason I'm not getting email notifications even though I was getting them a few weeks ago.

Below is my IDL code for reading the hardware information for Adak East. I get site.status=1 for example 2 when the radar
was operating. The other two examples (before and after the radar was operating) return an integer rather than a structure. So I can't ever get site.status=-1.

I think this is the correct behaviour; it's just not how I interpreted your original description of this PR:

...on this branch the correct value will be returned (ie 1 for active or -1 for inactive)

---

;read in radar network information
fname=getenv('SD_RADAR')
openr,unit,fname,/get_lun,/STDIO
network=RadarLoad(unit)
free_lun,unit

;import hardware information for Adak East (stid=209)
stid=209
hdwpath=getenv('SD_HDWPATH')
s=RadarLoadHardware(network,path=hdwpath)
r=RadarGetRadar(network,stid)

; (1) before radar began operating
site=RadarYMDHMSGetSite(r,2011,1,1,0,0,0)
print,size(site)

; (2) during radar operation
site=RadarYMDHMSGetSite(r,2016,1,1,0,0,0)
print,size(site)
print,'status: ',site.status

; (3) after radar ceased operating
site=RadarYMDHMSGetSite(r,2023,1,1,0,0,0)
print,size(site)

[egthomas]

@ecbland thanks for the example - I see what you mean. If you try a radar that has alternated between status flags of +1 and -1 (e.g., Halley / stid=4) then you can see a site.status equal to -1.

I think the original problem I was trying to fix was that the site.status value being returned did not match the values in the hdw.dat files. I worry that changing the behavior any further (ie returning an integer of 0 rather than a site structure if the date is before or after the start/end dates in the radar.dat file) may have unintended consequences for other RST code.

[pasha-ponomarenko]

@egthomas, I agree that changing the output from a structure to a single number might break some code downstream.
It will definitely break my current IDL code for reading site information. 🤔

[ecbland]

Thanks @egthomas, now I understand. I indeed get site.status=-1 for Halley for the relevant dates. I'll merge this now...