Using act object attributes to store important information about act

[kenkehoe]

I've update my code to look for datastream as a global attribute. If one does not exist I add __datastream. This would allow viewing the required information from downstream tools and a way for the information to be added to the object without the need to add act hidden variables. My downstream tool will check for both datastream and __datastream.

[kenkehoe]

I see the plotting routine was updated to not use the act object date range attributes, but it looks like it is still using the act object datastream attribute. I can set it using the act object setter method but I think we should not use that as it makes debugging the plot title more difficult.

[AdamTheisen]

@kenkehoe what are your thoughts on this? Still something we should update?

[kenkehoe]

I think we should not require this information for any of our tools, and use try/except around them where we do use them. There may be a few more out there that should be updated. I recently ran into one looking for "site" that caused a problem.

[AdamTheisen]

It looks like it would be these lines here that we update to be under the attrs attribute if we were to update right?

arm_ds.act.file_dates = file_dates
arm_ds.act.file_times = file_times
is_arm_file_flag = check_arm_standards(arm_ds)

if is_arm_file_flag.NO_DATASTREAM is True:
    arm_ds.act.datastream = "act_datastream"
else:
    arm_ds.act.datastream = arm_ds.attrs["datastream"]
arm_ds.act.site = str(arm_ds.act.datastream)[0:3]
arm_ds.act.arm_standards_flag = is_arm_file_flag

@rcjackson @zssherman what do you think of making a change like this?

[kenkehoe]

I'm actually more concerned about any of the plotting or other tools needing these attributes if the data is read in without the ACT reader. I think we should be careful getting these attributes in any of the downstream processes, and they should fail gracefully if used.

[rcjackson]

I am in agreement with Ken. We should just have the plotting tools check for the desired attribute, and have them gracefully finish with a default value for the attribute if the attribute is not there. Chances are, it's only affecting the text which can be modified after the fact anyways. Datastream is used to provide key names for each dataset in the display object, but I do have it set to where it will require the user to specify the key names in a dictionary if datastream is not an attribute.

…

________________________________ From: Ken Kehoe <[email protected]> Sent: Thursday, October 10, 2019 3:51 PM To: ANL-DIGR/ACT <[email protected]> Cc: Jackson, Robert <[email protected]>; Mention <[email protected]> Subject: Re: [ANL-DIGR/ACT] Using act object attributes to store important information (#8) I'm actually more concerned about any of the plotting or other tools needing these attributes if the data is read in without the ACT reader. I think we should be careful getting these attributes in any of the downstream processes, and they should fail gracefully if used. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#8>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AFIQA5C3P65BV43AGAGHNS3QN6IU5ANCNFSM4HARDTGQ>.

[AdamTheisen]

Just to confirm with @rcjackson, there are no major issues if I change the attributes currently stored in obj.act to be stored under the obj.attrs area with the rest of the attributes and then adjust the downstream code as needed correct? I will then work to adjust the codes to not require these. Sound ok?

[AdamTheisen]

Closing out. ACT attributes have been ported over to xarray attrs