Comments (8)
I've had to make a few changes to logging functions / calls as part of building the testing module (#79). That got me thinking about how to clean up the logging in VIC. This link seems to lay out one option that could work for us: http://c.learncodethehardway.org/book/ex20.html. Maybe you guys have other thoughts?
from vic.
That looks fine to me. The other option would be log4c (http://log4c.sourceforge.net), which I think is a bit more of an actual logging library (logging to files, etc. rather than just printing to stderr), but I like the low overhead of the macros that you are pointing to.
In some ways, VIC's error handling is even more lightweight, in that for any real error, the model should DIE rather than try to recover (it'd be different if we were putting together a plotting server or something like it). That means that the "goto error" part is strictly not even needed. I remember implementing something like that (with the "goto error" which is placed after the return statement at the bottom of the function) at some point, but I suggest for VIC we just crash rather than try to close down cleanly (close files, release memory, etc.).
Would you plain to replace all the error checking with this or for now just replace all the vicerror(), nrerror() and fprintf(stderr) calls?
On Nov 18, 2014, at 1:39 PM, Joe Hamman [email protected] wrote:
I've had to make a few changes to logging functions / calls as part of building the testing module (#79). That got me thinking about how to clean up the logging in VIC. This link seems to lay out one option that could work for us: http://c.learncodethehardway.org/book/ex20.html. Maybe you guys have other thoughts?
—
Reply to this email directly or view it on GitHub.
from vic.
I agree we want to ovoid recovering from an error. Crashing with an informative error message is where I'd like to point us.
Certainly replacing the existing error and print statements would be a start but I wouldn't rule out the "goto error" method either. I don't have strong feelings about how to do this (I just stumbled upon this so I was just throwing it out there).
from vic.
Just to make sure you know the background: the CONTINUEONERROR option (TRUE
by default) was motivated several years ago by the desire to NOT die on
error. But the reason behind that was that VIC was crashing a lot in
scattered grid cells in the frozen soils function; people wanted to be able
to get the 95% of the results that didn't crash. Those crashes have long
since been fixed, so perhaps CONTINUEONERROR is no longer needed...
On Tue, Nov 18, 2014 at 1:59 PM, Bart Nijssen [email protected]
wrote:
That looks fine to me. The other option would be log4c (
http://log4c.sourceforge.net), which I think is a bit more of an actual
logging library (logging to files, etc. rather than just printing to
stderr), but I like the low overhead of the macros that you are pointing
to.In some ways, VIC's error handling is even more lightweight, in that for
any real error, the model should DIE rather than try to recover (it'd be
different if we were putting together a plotting server or something like
it). That means that the "goto error" part is strictly not even needed. I
remember implementing something like that (with the "goto error" which is
placed after the return statement at the bottom of the function) at some
point, but I suggest for VIC we just crash rather than try to close down
cleanly (close files, release memory, etc.).Would you plain to replace all the error checking with this or for now
just replace all the vicerror(), nrerror() and fprintf(stderr) calls?On Nov 18, 2014, at 1:39 PM, Joe Hamman [email protected]
wrote:I've had to make a few changes to logging functions / calls as part of
building the testing module (#79). That got me thinking about how to clean
up the logging in VIC. This link seems to lay out one option that could
work for us: http://c.learncodethehardway.org/book/ex20.html. Maybe you
guys have other thoughts?—
Reply to this email directly or view it on GitHub.—
Reply to this email directly or view it on GitHub
#64 (comment).
from vic.
You really only need the "goto error" method if you want to recover. Otherwise you can just exit ...
On Nov 18, 2014, at 2:24 PM, Joe Hamman [email protected] wrote:
I agree we want to ovoid recovering from an error. Crashing with an informative error message is where I'd like to point us.
Certainly replacing the existing error and print statements would be a start but I wouldn't rule out the "goto error" method either. I don't have strong feelings about how to do this (I just stumbled upon this so I was just throwing it out there).
—
Reply to this email directly or view it on GitHub.
from vic.
Yes - I am aware of that option (and the problems that people then had in converting incomplete time series to netcdf). I think it has served its purpose in the past, but if it falls by the wayside as part of the logging upgrade that is fine by me. This is basically something that is specific to the driver. It does not work in image mode anyway (incomplete fields?!), but maybe should be maintained in classic mode. We can probably modify the check() or log_error() macros in that case to not exit but go to the next grid cell.
On Nov 18, 2014, at 2:25 PM, Ted Bohn [email protected] wrote:
Just to make sure you know the background: the CONTINUEONERROR option (TRUE
by default) was motivated several years ago by the desire to NOT die on
error. But the reason behind that was that VIC was crashing a lot in
scattered grid cells in the frozen soils function; people wanted to be able
to get the 95% of the results that didn't crash. Those crashes have long
since been fixed, so perhaps CONTINUEONERROR is no longer needed...On Tue, Nov 18, 2014 at 1:59 PM, Bart Nijssen [email protected]
wrote:That looks fine to me. The other option would be log4c (
http://log4c.sourceforge.net), which I think is a bit more of an actual
logging library (logging to files, etc. rather than just printing to
stderr), but I like the low overhead of the macros that you are pointing
to.In some ways, VIC's error handling is even more lightweight, in that for
any real error, the model should DIE rather than try to recover (it'd be
different if we were putting together a plotting server or something like
it). That means that the "goto error" part is strictly not even needed. I
remember implementing something like that (with the "goto error" which is
placed after the return statement at the bottom of the function) at some
point, but I suggest for VIC we just crash rather than try to close down
cleanly (close files, release memory, etc.).Would you plain to replace all the error checking with this or for now
just replace all the vicerror(), nrerror() and fprintf(stderr) calls?On Nov 18, 2014, at 1:39 PM, Joe Hamman [email protected]
wrote:I've had to make a few changes to logging functions / calls as part of
building the testing module (#79). That got me thinking about how to clean
up the logging in VIC. This link seems to lay out one option that could
work for us: http://c.learncodethehardway.org/book/ex20.html. Maybe you
guys have other thoughts?—
Reply to this email directly or view it on GitHub.—
Reply to this email directly or view it on GitHub
#64 (comment).—
Reply to this email directly or view it on GitHub.
from vic.
My vote would be to use the simpler, macro based, approach. I went ahead and tried out this approach with some simple tests in VIC and it works like a charm (#165).
I think we can cleanly sort out the error handling with regards to the "goto" functionality and the CONTINUEONERROR
option.
from vic.
closed via #173
from vic.
Related Issues (20)
- classic and image drivers fail to build - Ubuntu 22.04 HOT 5
- NetCDF: Invalid dimension ID or name: Error getting dimension id MISSING HOT 1
- Segmentation fault when running image driver with LAKES = TRUE (cells with and without lakes) HOT 1
- layer 0 mineral bulk density (0.77000) must be less than mineral soil density(0.57000)
- New - Compile failure -- Resolved HOT 1
- ERROR: set_force_type.c:138: errno: None: Must supply netCDF variable name for WIND forcing file number 1
- [ERROR] ../../vic_run/src/CalcAerodynamic.c:119: errno: Numerical result out of range: Trunk space height below "center" of lower boundary
- Resloved--Can't Run vic_image.exe -g global,txt, and the error occured in the file of set_forcing_type.c HOT 1
- [QUESTION] Soil moisture fraction output with VIC v5
- Wpwp_FRACT MUST be <= Wcr_FRACT.
- multiple definition of 'xxx'; ... first defined here HOT 1
- Maximum Energy Error
- Clarification of forcing units HOT 1
- Why are there negative values in the sublimation of the snow in the canopy intercept in VIC 4.2.d?
- Compilation error with VIC5.1.0: "collect2: error: ld returned 1 exit status" HOT 3
- Erroneous VIC version reporting in image driver?
- VIC Image Driver CPU Limited? Ways to increase memory use? HOT 1
- an error in docker_vic HOT 2
- Bug in classic driver in VIC 5.1.0, not able to read forcing data HOT 1
- Dose it include the both infiltration and saturation excess runoff mechanisms like Liang and Xie (2001)?
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from vic.