Comments (5)
Honestly, I've never even looked at the ross.csv file. Is a per-run generated file useful to you? What sort of information should be included in this file?
from ross.
In my model, I actually use the code in ross-stats to output some useful data to stderr to catch with a script. However, sometimes I realize that I need information like percent remote events, efficiency, ROSS kernel options, and other stuff. I was hoping that ross.csv contained all of the run time information from the previous ROSS run.
Personally, I would find this useful since sometimes I need info that I forgot to include in my custom stats output. CSV works really well since I can just dump it into whatever program I need to check it. The perfect ROSS CSV file would contain:
- The command used to run this instance of ROSS
- All of the stats displayed at the end of the run
- Error status if ROSS failed with some memory issue
- The time/date of the run
To me it makes sense that a ross.csv file would contain a big dump of ROSS runtime info for each run. Having it be nondestructive (as it seems to be now) would also be great.
from ross.
In part, you are also asking for #30. So, since I'm going to overhaul how ROSS output is handled, how do these options sound:
- the option to pretty-print the run-time options:
- to stdout
- destructively to a specified file (name specified by the model developer)
- or not at all
- the option to pretty-print the end statistics:
- to stdout
- destructively to a specified file (name specified by the model developer)
- or not at all
- the option to CSV print run-time options, non-destructively to a CSV file (would only include ROSS core/kernel options aka would not include model options or RIO/other component options). Should this really be an option that the user can turn off?
- the option to CSV print end statistics (or end-status), non-destructively to a CSV file (would only include ROSS core statistics aka would not include model statistics). Should this really be an option that the user can turn off?
Each option would be separate, so you could choose any combination of the 4 above.
Note: For 1 and 2, I could add a timestamp to a specified filename (to make it non-descructive)
Note: For 3 and 4, API could easily be improved as to incorporate model registered options/stats, but I'll save that for later.
from ross.
Those options look great to me! I've never looked at ross.csv either :). As for defaults, I'd prefer opt-in behavior, i.e. no output unless the user asks for it.
Perhaps you can use 4 toggles:
--pretty-env=<file>
--pretty-stat=<file>
--csv-env=<file>
--csv-stat=<file>
where file is some path - no option prints to stdout, whereas "stdout" and "stderr" arguments print to stdout/stderr, respectively. It's useful to be able to keep stdout clean for parsing user-defined output. You can check for file(s) existence at startup and error out if they exist.
Unique suffixes should be opt-in as well I think, with an option such as --unique-output-suffix option (or similar). When I run model ensembles, I'm already separating the filenames. Uniqueness ends up being useful for the edit/debug cycle.
from ross.
The CSV printing will be an ON/OFF option only. If we want the power to append to the CSV file, we'll have to attempt to ensure that the actual number/order of command-line options doesn't change. So, ROSS will create CSV files per version: ross-#hash#-clo.csv
(command-line options) and ross-#hash#-end.csv
(end state: stats or error msg).
As for opt-in behavior, we can certainly do that with sometime like --csv
. It might be best to keep the two CSV files linked with the same flag, that way each line in the clo file matches a line in the end file.
from ross.
Related Issues (20)
- Build Failing HOT 6
- Can't call ROSS multiple times HOT 2
- Running gvt-7o`clock Algorithm for GVT Computation HOT 2
- Sending - Receiving Messages HOT 4
- Interesting Run Time Results With Mattern`s GVT HOT 2
- Array pointers in event messages? HOT 6
- Out of event memory fails too quietly HOT 2
- CMake clean up HOT 6
- Memory Allocation HOT 2
- improve testing HOT 5
- CMake Object Library HOT 7
- No file tw-memory.c HOT 2
- Multi threading version HOT 2
- about GVT_force_update HOT 8
- CODES develop integration HOT 2
- RIO event management
- Formalize ROSS API HOT 3
- Out of Free Events Error Handling HOT 3
- Simulation not completing HOT 3
- Issues building any of the stable models HOT 3
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 ross.