Mods to README.md for v0.1.0 release - CCPP only

[davegill]

For v0.1.0, this is a set of mods to the README.md file. I am not able to get the file to "look" nice in HTM without the cheating uses of the

<pre>
blah, blah, blah
</pre>

html tags.

[grantfirl]

Dave, I read through your changes to the README.md file and they add a lot to the bigger picture, especially for an outside user. I did have a question about the difference between suite definition XML files in /examples versus those found in src/tests. Which location should suite XML files ultimately reside? For the requirements section, should there be something about the libxml version? I noticed a typo on line 204 (directoty). In fact, aren't lines 204-213 redundant?

I can't comment on how doxygen handles parsing the file for formatting since I have no way of pulling in your changes and running doxygen until we go ahead and accept the pull request, right?

[grantfirl]

Dave, I think that Tim is on vacation through today. FYI.

[davegill]

@grantfirl @t-brown
Thanks for the typo detecting - fixed.

The "tests" directory and the "examples" directory are two separate beasts. Tim uses the "tests" dir to make sure that things are working internally for the standalone CCPP. On the other hand, we want people to use the "examples" dir as where they should get their XML suite definition templates.

I agree that we let Tim review before pulling the trigger on this PR.

[t-brown]

Dave, Grant.

I've reviewed your changes. They are good! As Grant points out, it should help the users a lot.

As a side note, I did some work on the suite (9232538) so users can just call ccpp_run(). Also subcycling is taken into account. Should this hold off to v0.1.1?

I was thinking about the term ipd within the XML, should this be renamed param or something? So as to move away from the general IPD term?

[davegill]

@grantfirl @t-brown

1. I would say that we hold off on upgrades to v0.1.0.
2. I agree that the "ipd" term in the XML files is problematic. But similar to item 1 above, I think we address this after v0.1.0. As for what to call it, "param" or "phy_param" or variant? We want this to be general enough that we can easily be putting diagnostic code in place, positive def checks, NaN checks, etc. Maybe "schemes"?