search

Smithsonian / ngehtsim

A repository of simulation material for the ngEHT collaboration
MIT License
5 stars 3 forks source link

arrayname and site bug #3

Closed ptiede closed 2 years ago

ptiede commented 2 years ago

First issue!

There seems to be an issue when you specify the sites in the yamlfile but you don't include the arrayname. For example,

# array: 

# list containing the array site names
sites: ['LMT','BAJA','CNI','HAY','LAS','OVRO','JCMT','SMT','GLT','APEX','GARS','GAM','CAT','BOL','BRZ','PIKE']

creates very sparse coverage at 345 GHz, while

array: 

# list containing the array site names
sites: ['LMT','BAJA','CNI','HAY','LAS','OVRO','JCMT','SMT','GLT','APEX','GARS','GAM','CAT','BOL','BRZ','PIKE']

works fine.

dpesce commented 2 years ago

Good catch!

It turns out that this issue pops up anytime both (1) an array name was specified and (2) some sites were specified.  The reason you see it when commenting out the array name is because the default settings load up with the array name "EHT2022," and this array name sticks around when there is no "None" entry in the array field of the input yaml file to overwrite it.  When it then comes time for the code to populate site properties, it does so thinking that the array is EHT2022, which means that most sites are forced to have no multi-frequency capabilities (which is why FPT observations break but non-FPT ones don't).

Anyhow, I've now fixed it with an explicit check for this issue during obsgen initialization. Things should now work regardless of whether you specify and array and sites at the same time, or whether you comment out the array line in the input yaml file. The default behavior when the code is presented with both an array name and a list of sites will now be to give preference to the list of sites.