Cactus: don't print schedule tree by default

Issue #1908 open
Frank Löffler created an issue

Currently, Cactus always prints the schedule tree by default (flesh::cctk_show_schedule = "yes"). I assert that hardly anybody looks at this output, and for most, in fact, it is a nuisance to always have to "scroll down" to more useful information.

Thus, I propose to change the default of the flesh parameter cctk_show_schedule to "no".

Keyword:

Comments (7)

  1. Ian Hinder
    • removed comment

    It depends what you are looking for. There is a lot of information in standard output that is not needed all the time, but when you do need it, it is quite useful to have. Maybe instead we could insert some descriptive phrases in the output so that you can quickly search for what you want, rather than having to scroll? I would find that very useful.

    Somewhat related: the CST outputs a lot of information about the number of files processed, schedule blocks etc. These clutter the early stage of the build log, and seem to be really pointless, much more so than the schedule tree at runtime. I have thought for a while that these should just be omitted. It's more important to see the output of the CST, scripts runs, etc, and the start of compilation, than counts of number of CCL files, which is presumably only useful for debugging the CST itself.

  2. Frank Löffler reporter
    • removed comment

    I agree that some 'phrases' might be nice. I also agree that the scheduling tree isn't the only information you hardly need when running simulations, or building executables. We have to do something to cut output like this down to a minimum that is useful for most people, along with the possibility to easily enable more output when needed. I've chosen the schedule tree because of it's sheer length in terms of lines, and for the not-very-invasive nature of the change (just the default value of an already existing parameter).

    What I would like to avoid is that this ticket becomes a collection of wishes for very different things, a kind of über-ticket for cutting down on the output while building/running. We could open a ticket like that, and link this ticket there, if this is felt to be helpful. I would like to concentrate here on the default for printing the scheduling tree: should this be 'yes', or 'no'?

  3. Roland Haas
    • removed comment

    I actually look at the schedule rather often. In particular when I use a thorn in a new way. Eg. my ReadInterpolate thorn must be called at a specific place in the schedule or when debugging the issue with Dissipation and the change an AHFinderDirect scheduling recently. Since the printed schedule tree (together with hardwired knowledge about the modes) is the only concise way to know when things execute I would rather not miss it.

  4. Frank Löffler reporter
    • removed comment

    Replying to [comment:3 rhaas]:

    I actually look at the schedule rather often. In particular when I use a thorn in a new way. Eg. my ReadInterpolate thorn must be called at a specific place in the schedule or when debugging the issue with Dissipation and the change an AHFinderDirect scheduling recently. Since the printed schedule tree (together with hardwired knowledge about the modes) is the only concise way to know when things execute I would rather not miss it.

    I agree that it is useful while debugging, or writing new thorns. But don't you agree that it is rather unusual to look at the output once you do production simulations? During debugging it would be easy to change from the default.

  5. Erik Schnetter
    • removed comment

    I suggest the following: * Disable the schedule output to stdout by default * Always output the the schedule into a new file * For good measure (sorry, Ian!), output all level three warnings and replicate all stdout to this new file as well Thus stdout would be much smaller and more interesting. The new logfile would contain all the gory details.

    In the past, we've tried to decide what to output and what not, and how to let people filter it ahead of time. We could just output three files: * stderr, for when things go wrong * stdout, for things that are interesting most of the time, to many users * a log file, for everything else that can be output without slowing down the simulation

    With this in place, we can easily pare down on stdout, without having to deal with "but one time I needed this information, don't take it away from me" arguments.

    Also -- none of this should happen before the release.

  6. Frank Löffler reporter
    • removed comment

    I agree with all of the points. The first two should be easy to do. The third might require re-writing a bit of how Cactus handles output though (replicating output).

    And, of course this wasn't meant to be in the release. I didn't tag the ticket with the release milestone, but should probably have made this more clear.

  7. Log in to comment