Timestamp format for external biomet file

Environmental Forum Forums EddyPro Timestamp format for external biomet file

This topic contains 6 replies, has 3 voices, and was last updated by  vitaly 5 years, 3 months ago.

Viewing 7 posts - 1 through 7 (of 7 total)
  • Author
    Posts
  • #1441

    schan
    Participant

    Hi.

    I am using a custom data acquisition program that generates separate high frequency and ‘biomet’ data files. I successfully ingested the high frequency data into EddyPro but I am having difficulty bringing the ‘biomet’ data- specifically with formatting the ‘biomet’ data timestamp. I am acquiring the ‘biomet’ data every 2 seconds (0.5 Hz) and saving to a comma separated file. The online help files (http://envsupport.licor.com/help/EddyPro4/Default.htm#Biomet_Data_Format.htm) do not specify how to define the timestamp at intervals smaller than 1 minute (i.e., how do I specify a column with seconds data). I currently have files labeled yyyy, ddd, HH, MM but continue to get the following error:

    At line 1017 of file: read_ext_biomet_files.f90

    Fortran runtime error: Index ‘0’ of dimension 1 of array ‘dayofyear’ below lower bound of 1

    I have tried a number reformatting tricks to get EddyPro to run but have not had any luck yet. The help files also specify that the minutes time data (MM) must be integer values so I cannot create a fractional minute, right?

    Any suggestions appreciated.

    Here is a short section of the first few columns of the datafile:

    LoggerID, TIMESTAMP_1, TIMESTAMP_2, TIMESTAMP_3, TIMESTAMP_4, TIMESTAMP_5,

    ”, yyyy, ddd, HH, MM, SS,

    101, 2013, 095, 14, 5, 2,

    101, 2013, 095, 14, 5, 4,

    101, 2013, 095, 14, 5, 6,

    101, 2013, 095, 14, 5, 8,

    101, 2013, 095, 14, 5, 10,

    101, 2013, 095, 14, 5, 12,

    101, 2013, 095, 14, 5, 14,

    101, 2013, 095, 14, 5, 16,

    101, 2013, 095, 14, 5, 18,

    101, 2013, 095, 14, 5, 20,

    101, 2013, 095, 14, 5, 22,

    101, 2013, 095, 14, 5, 24,

    101, 2013, 095, 14, 5, 26,

    101, 2013, 095, 14, 5, 28,

    101, 2013, 095, 14, 5, 30,

    #1774

    gerardo
    Participant

    Hi there,

    “seconds” are not foreseen in EddyPro’s timestamp model for biomet measurements.

    I guess there are two options at hand:

    1. pre-process the biomet files averaging all values at 1 minute time steps and then follow normal EddyPro’s rules;

    2. Just keep the files you have and change the header label “TIMESTAMP_5” (referred to seconds) to something else (say “VOID”). This way, EddyPro will only consider the time stamp info until the minute. Not sure what exactly will happen: (1) EddyPro will use only the last value of each minute; (2) EddyPro will actually average all values. This can be easily checked in the result file, but anyway I would not expect the difference between (1) and (2) to be relevant.

    Hope this helps.

    Thanks,

    Gerardo

    #1778

    schan
    Participant

    Hi Gerardo.

    Thank you for the prompt reply. I have tried both of your suggestions. However, I continue to receive the same error message, so I suspect that the ‘seconds’ issue is independent of the problem that I am having. This is the error message that I receive:

    At line 1017 of file: read_ext_biomet_files.f90

    Fortran runtime error: Index ‘0’ of dimension 1 of array ‘dayofyear’ below lower bound of 1

    I tried feeding the biomet data using two columns for month and day (mm, dd) instead of DOY (ddd). The program ran but for every averaging period, this was the output from the console:

    No valid biomet records found for this averaging period. Continuing without biomet data.

    I must have an error in the timestamp formatting. Do timestamp information in the biomet files need to be padded with zeros (i.e., April = 4 or 04)?

    Could this be an issue with the format of the high frequency data that I am using? I have binary files (1 per day) for the high frequency data. Each is formatted as (header-ddd-yyyy-HH-MM.ext) with HH and MM always 00 since these are daily files.

    Thank you for your help.

    #1781

    gerardo
    Participant

    Hi Schan,

    actually, you may try padding at least the “minute” field of the timestamp. I don’t have it on top of my mind, but I believe I have been making it such that you don’t need to pad anything, except for the minute. Actually, lately I also fixed this, so that now you don’t need to pad anything, but this is not yet available in 4.1.

    Anyway, would you mind posting:

    – 1 raw file

    – the .metadata file

    – the .eddypro file

    – the biomet file

    here on the forum (or to my email), so that I can have a look?

    Thanks!

    Gerardo

    (gerardo.fratini@licor.com)

    #1792

    gerardo
    Participant

    Hi there,

    I found several issues while trying to process your biomet files.

    Your files are well formatted. However:

    1. The current version of EddyPro (4.1) requires you to pad the “minutes” with zeros to have a constant string length of 2 characters.

    2. Version 4.1 also won’t be able to accommodate the 2-seconds time step, so please use the 1-min averages

    3. Different from what is written on the Web Help, please make sure that the timestamp fields are in the first columns in the biomet file, i.e. eliminate the Logger ID field (or move it after the timestamp). We will revise the Web Help soon in this respect.

    Please note that issues 1. and 2. will be resolved in the forthcoming version 4.1.1.

    Issue 3. will instead be addressed in a future release.

    Thanks,

    Gerardo

    #1795

    schan
    Participant

    Gerardo,

    Thank you for the help. Your suggestions solved my problem(s) and EddyPro now reads the biomet file. I wanted to also share that I had to remove leading spaces from the timestamp fields for this to work properly. As mentioned, I first padded them with zero(s) to ensure consistent length.

    I look forward to the updates in the future releases.

    Thanks again.

    #1846

    vitaly
    Participant

    Hi Gerardo,

    I also faced this problem with a length of timestamp fields. “Padding” with zeroes solved the problem, but before I look into the forum, it made me frustrated for a couple of hours )

    Look forward for the new releases.

    Regards.

Viewing 7 posts - 1 through 7 (of 7 total)

You must be logged in to reply to this topic.

Comments are closed.