halx
commented
8 years ago One practical thought on this. I think the code should have an understanding of what the various analysis methods "mean". Not sure if there's something in place but e,g,
all_methods = set(['TI','TI-CUBIC','DEXP','IEXP','GINS','GDEL','BAR','UBAR','RBAR','MBAR']) ti_methods = set(['TI','TI-CUBIC']) bar_methods = set(['DEXP','IEXP','GINS','GDEL','BAR','UBAR','RBAR','MBAR'])
other methods if applicable
selected_method = set(P.methods) # or via argparse
if not selected_method & bar_methods: # intersection do_bar = None
if u_klt is None: selected_method = selected_method - bar_methods
davidlmobley
dotsdl
nathanmlim
mrshirts
There is currently a lot of cruft growing in the code which is basically down to design choices.
Here some suggestions: The parsers should be designed in a "polymorphic" fashion such that the main code does not need to know anything about the individual parser codes. This implies that a clear interface and a specification must be designed to define what data is passed in and what is passed out and in what form. It is the responsibility of the parser code to signal back what it can and cannot do. E.g., as it stands now, dhdlt should be None if MD code can't do TI or u_klt should be None if it *BAR analysis can't be done. Energies should be converted to a "canonical" form or it should be signalled back to the main code what the units are. This will relieve the main code maintainer to do code-specific clean-up operations.
Optparse should be replaced with argparse.
The globals need to go as this is really bad programming style. The problem with this is that all these variables are accessible throughout all of the module which mean that they can be modified anywhere. This can create hard to track down bugs (all you need is a second person messing around there...).