profile.txt variable definitions

[zli867]

Hi Joel,

Although the BlueSKY returns the result, I have received a error message:
2022-06-23 18:35:03,926 WARNING: Failed to compute min/max of WSPD: 'NoneType' object is not iterable
It happens when I run FEPS model. I checked the profile.txt and it does not have a variable called WSPD. The wind speed is named as WSP. I checked the code:
https://github.com/pnwairfire/met/blob/60c7f9e42a0ae7a7768bcc4f02f60effa861ed57/met/arl/arlprofiler/profileparser.py#L417

You have used WSPD as the default name of wind speed. Do you think the ARL data does not have a consistent naming convention? Actually, I download the data from NOAA. It provides for HYSPLIT running. Also, the same issue happens when I used a WRF to ARL converter which is provided by HYSPLIT:
#228 (comment)

I am not sure whether Susan told you the problem I met in SEV model yesterday. It is interesting that the same thing happens in FEPS. I do a local test, sometimes it does not report this error sometimes it does. While both of these situations do not generate meteorology successfully. I can share the input I used:
https://drive.google.com/drive/folders/1x2tyw6mSH9sVdkeb26rd2kCvjhCzFAc8?usp=sharing

I am not sure whether name convention causes the problem. Do you have any ideas for it?

Thanks,
Zongrun

[jdubowy]

Hi Zongrun,

Some of the bluesky code, including met naming conventions, came from the older version of bluesky (v3.5, which isn't opensource). That was developed before my time on the AirFire team. We could update the met package to support aliases, but I'll first talk to Robert and others who deal with ARL data.

[zli867]

Thanks for your help. I have something need to update. I think the naming convention you used is correct. The reason that WSP is shown in my profile.txt is that the length of string for each row is not set correctly.

The last column of my profile.txt is WSP and unit is m/ in my profile.txt. I believe the correct profile.txt should uses WSPD and m/s as the last column. Using a fixed length of string to write each row of profile.txt could cause the problem.

The docker version of BlueSKY shows the same problem and I guess the reason could not be my setting of BlueSKY. I believe Robert and others have an answer of it.

[jdubowy]

I don't understand your comment. Do you think there's an issue in the profile binary included in the bluesky docker image? Did you use profile or bulk_profiler_csv, or did you use a version of your own?

[zli867]

I am using the latest version you have updated. I guess the arl converter is written by FORTRAN (NOAA uses FORTRAN code to do the conversion). I am not really familiar with FORTRAN but I have heard that execution results from the same code may has differences under different compiler (intel or gfortran) (if I am wrong, please correct me). So, I decide to use your environment (docker version) to check whether the problem is caused by differences between my environment setting and yours. The results show that both my local BlueSKY and your BlueSKY on cloud have the same problem. I guess the issue is still at the arl converter code. In FORTRAN, we need to state the length of string. I guess if the length of string is not enough in the statement, it could cause this problem.

[jdubowy]

I'm not the person to ask about either FORTRAN or ARL conversion code. If you suspect that there is an issue in the ARL conversion, and not in bluesky or the profile binary, I'd contact Robert outside of github.