Rethinking wording around input/output

[gonsie]

One point of confusion with some users is the use of the wording for the "input" and "output" command line options. Users sometimes think that these files are for humans, when really we are connoting files that the tools read & write.

In thinking about re-branding these options across the tool suite, I've come up with following list of potential renames:

• in / out
• from / to
• read / write
• load / save
• load / store
• load / dump
• consume / produce

We should clarify that these actions are for the tool "state" or "cache". We may want to write documentation about what we mean by a cache and how each tool modifies the cache. We should also think about the naming convention of the argument. I would prefer to stay away from possible clashes with tools that we mimic, so using a only a long option might be the way to go.

---

Thoughts? I'm partial to "load" and "store" of a "cache", with the options being --load / --store or --load-cache and --store-cache

[dsikich]

@gonsie I would say read/write or load/store make the most sense to me.

[gonsie]

Part of our conversation about this brought up the fact that users are allowed to create the file name, and many users with default to a .txt extension. This can lead to confusion when a user tries to look at the data later, and ends up with a screen of jibberish.

I think we should:

• put a .mfu file extension on to whatever path value the user has given us
• refer to this file as "the mfu file" in our documentation and usage strings
• add a page to the RTDs that describes this file.

in addition to changing the input/output option names.

[gonsie]

thought! We could also use the terminology pipe-in and pipe-out since this is basically what users are trying to achieve. Yes a “pipe” is a specific type of file on the file system, but I don’t MPI users typically think about that.