New vs. old keywords

[Mike Towler]

Dear all,

You may or may not be aware that CASINO has two different and mutually incompatible sets of keywords that may be used in the input file. The new set (introduced in CASINO 2.2 many years ago) have slightly different and allegedly more convenient meanings. To give you an idea, when they were introduced the different sets were as follows:

Code: Select all

New set:

  * VMC_NSTEP         * VMC_NCONFIG_WRITE * VMC_DECORR_PERIOD
  * VMC_AVE_PERIOD    * VMC_NBLOCK        * VMC_EQUIL_NSTEP
  * VMC_NTWIST        * VMC_REEQUIL_NSTEP
  * DMC_TARGET_WEIGHT * DMC_EQUIL_NSTEP   * DMC_STATS_NSTEP
  * DMC_EQUIL_NBLOCK  * DMC_STATS_NBLOCK  * DMC_AVE_PERIOD
  * DMC_DECORR_PERIOD * DMC_TRIP_WEIGHT   * DMC_NTWIST
  * DMC_REEQUIL_NSTEP * DMC_REEQUIL_NBLOCK
 
Old set (in one-to-one correspondence with the above):

  * NMOVE            * NWRCON            * CORPER
  * NVMCAVE          * NBLOCK            * NEQUIL
  * VMC_TWIST_AV     * NEQUIL_TA
  * NCONFIG          * NMOVE_DMC_EQUIL   * NMOVE_DMC_STATS
  * NBLOCK_DMC_EQUIL * NBLOCK_DMC_STATS  * NDMCAVE
  * CORPER_DMC       * TRIP_POPN         * NUM_DMC_TWISTS
  * NMOVE_DMCT_EQUIL * NBLOCK_DMCT_EQUIL

Now all the documentation and examples in the CASINO distribution use (understandably) the new set, and I have come to believe that the time has come to remove support for the old set. This has led to some resistance on the part of a few long-term CASINO users.

The reasons for my attitude are as follows:

For users, forcing them to use the new keyword set means:

- Typing 'casinohelp keyword' will produce lots of detailed output for the new keyword set and unhelpful stuff like '[DEPRECATED] nblock is the number of blocks' for the old set.

- CASINO comes with a set of examples with keywords that they recognize.

- The documentation and the manual are only understandable if you use the new keyword set.

- old-style keyword stuff is liable to get broken because I never use them, and my continuous testing and bug-hunting won't reveal problems.

For developers:

- We don't have to translate user queries into our preferred language, or update complainant's input files into the modern idiom..

- One of the things to be done quite soon is making CASINO come up with default values for all keywords even if they aren't supplied in input (leading ultimately to a 'Make the Answer Better' button in DFT for um.. idiots who don't know how QMC works i.e. people other than you lot). I don't want to have to do this for both keyword sets.

- We need to attract more developers who actually develop stuff, and reducing internal complications helps with this.

- Multiple keyword sets increase the likelihood of introducing errors.

- Error checking in the runqmc script becomes significantly simpler.

- The developers can all stop arguing about which keyword set is superior. I've used both, and I can tell you it's very easy to get used to either - so I think we should just get on with it.

All the above needs to be balanced against 'slightly pissing off the few people who continue to use the old keywords'. So my question is:

Does anyone out there other than er.. Neil and Dario (a) still use the old keywords, and (b) actually give a damn if I remove support for them completely?

Any and all commentary gratefully received.

Best wishes,
Mike

[Jhalak]

Its a good idea to drop the old stuff. Although, you may provide support (informally) for the old keyword users as well for some time, encouraging them to turn to the new sets.

[Bruno_Cramer]

Hi Mike

As I am using the last beta version of CASINO (Dec,2013) I am following the new keywords as recommended in the User`s guide.
Regards
Bruno

[Brian_Skinn]

As a new user, the 'new keywords,' though bulkier, are much clearer in what they mean. Will gladly only use the new ones.

-Brian

[Dan_Nissenbaum]

As a rule of thumb, if 1-5 years have passed it is acceptable to remove deprecated items. If 10 years have passed and deprecated items remain, they should either be removed, or the "deprecated" status should be removed. I haven't used CASINO since graduate school, but since this question was posted to the entire list, I thought I would answer with my experience from the world of programming.

Take care,
Dan Nissenbaum

[Emmanuel_Enukpere]

I learnt CASINO with the new keywords so I will encourage those in the ukd regime to change.
Afterall CHANGE is the order of life
Emman1

[Martin_Korth]

I also think that the new keywords are much clearer and I wouldn't mind if the old ones would not be available anymore.
Martin

[Mike Towler]

OK - executive decision time on this.

As you will have seen I sent out this question both to the mailing list and to this Forum (i.e. to the more than 500 people who supposedly use CASINO). We got 6 responses to the forum post saying we should junk them, and no responses whatsoever in support of retaining them.

At the end of the day then, it seems that the user base largely doesn't care, or thinks the old keywords should be removed. Of the developers only Neil and Dario care about this issue (and Pablo essentially doesn't see the point and thinks the time spent removing them would be better spent doing something else).

I think in the spirit of simplification and consolidation they should still be removed, but in deference to the views expressed, I'll postpone the removal until the version after next - likely to be around Jan 2015 - from now until then they will be marked as severely deprecated. So if you need to switch over you have one year to get used to the new set.. (a process which took me about a day when I converted years ago).. Everyone OK with that?

[Note that we won't be completely removing support for old input keywords; from 2015 I expect CASINO will recognize the presence of old keywords (as opposed to non-existent ones) and will simply refuse to run, asking the user to convert the old input to the new using the input_kw_conv utility that already exists in the current distribution. I suppose the conversion could even be automated!]

Anyway, that's more consideration than other codes show, believe me. To take the CRYSTAL software as an example, just the other year they managed to break every CRYSTAL input file in the world with a pseudopotential in it, just in the process of allowing the maximum angular quantum number to be l=5 instead of l=4. (As far as I can see this could have been avoided with just a few additional lines of Fortran..). They have also been known to make minor and non-backwards-compatible changes to their input file, and you won't catch them providing conversion utilities..!

M.