When I tried systematically zeroing out individual daily variables (precipitation, temperature, solar radiation, wind speed, humidity), I get identical results - no change in ET, PET, or water yield. Even setting all daily precipitation to zero produces the same total precipitation and water balance, indicating that the daily weather variables are not being read at all. This is especially interesting since the .OUT file shows "WEATHER DATA INPUT" and includes the name of the correct .DLY file.
When I use a slightly different format (more decimal places, no leading spaces), I get "wth exceeds start date, weather generated" in my .OUT file and significantly different (more realistic) results with a lower water balance closure error.
Has anyone else noticed this? Is there a specific formatting requirement I'm missing, or does APEX's daily weather reader have limitations I should know about?
Any insights would be appreciated - I want to ensure I'm actually using daily weather data when the model claims to be reading it. I've also attached my .DLY, .HLY, and .WP1 files.
Thanks,
Maya
Dear Maya,
After revisiting the file structure, I discovered that my *.DLY lines were not in the strictly fixed-column layout that the parser expects. Adding the required two leading spaces and keeping every numeric value within its six-character field allowed APEX to read the records correctly.
I confirmed the fix by:
Rerun the “zero-rainfall” test (ET and water yield dropped to near zero as expected),
Examine the first line of the *.DHY file (precipitation now mirrors my *.DLY value), and
Note that PET estimates and overall water balance now differ substantially from those produced by the monthly statistics.
In short, APEX will proceed silently with generated or monthly data whenever even a single daily line is misaligned, so a clean fixed-width format is essential. I’ve summarised the exact steps I followed below in case they help someone else.
2 Checklists to ensure APEX truly reads the daily fileVerify the simulation start date
Make sure IYR IMO IDA in APEXCONT.DAT is on or after the first record in your DLY file. If the start date precedes the first valid record, APEX will quietly generate weather until it catches up.
Reformat the *.DLY as a strict fixed-width
Two blank spaces, then three four-digit integers for year, month, and day.
Nine six-character reals for SRAD, Tmax, Tmin, precip, RH, wind, CO₂, REP, ORSD.
Use a text editor that shows column positions, or run WXPM3020.exe (it rewrites the file with correct spacing).
Check the control switches
NGN should list the daily variables you supply; the safest entry is 12345.
IWTH must match the station number in WDLSTCOM.DAT.
Keep the corresponding *.WP1 is in place. APEX still consults monthly stats for any missing days.
Delete or rename the *.WP1 temporarily to run APEX
If the model crashes, you know it is trying to read the daily file; if it runs, it is still falling back to monthly data.
Perform a “zero-rainfall” sanity check
Set the first week of precipitation in the *.DLY to zero and rerun. Daily output in *.DHY (RFV) and *.DWS (WYLD) should immediately reflect the change.
Compare PET and ET patterns
Daily PET/ET values should now vary smoothly with your SRAD, Tmax, and Tmin inputs. Large plateaus or blocky jumps often signal that APEX has reverted to monthly means.
Archive a clean copy of the validated *.DLY
Store the working version under version control or with a dated filename so you can roll back quickly if future edits introduce a spacing error.
Following these steps should keep APEX locked onto the daily forcing data and prevent the silent fallback to generated weather that caused the original confusion.
Good luck
Mahesh