Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add CheckSpecies module #366

Merged
merged 17 commits into from Sep 15, 2020
Merged

Add CheckSpecies module #366

merged 17 commits into from Sep 15, 2020

Conversation

trisyoungs
Copy link
Member

This PR adds a new module, CheckSpecies, to properly assess the atom types and forcefield parameters present in a species, particularly those applied automatically from within Dissolve.

Work includes:

  • Addition of new keywords IntegerStringVectorKeyword and IntegerDoubleVectorKeyword allowing general input of a set number of integers (in this instance, atom indices) followed by a variable list of strings or doubles. The underlying information is stored in a std::vector of std::tuple, with the tuple containing further std::vectors of the integer and string/double data.
  • Updating atom type names in the OPLS-AA forcefield, some of which were using asterisks that were interpreted as wildcards when in fact they are purely identifiers.
  • Updating the NETA system test to thoroughly check applied atom types and terms from the automatic typing routines, rather than just assume that the successful application of terms means the correct application of terms.

Notes:

  • The new keyword classes could be template-driven, but as they are relatively short and would require specialisations this was not performed.

@trisyoungs trisyoungs added this to In progress in Sprint: September 2020 1 via automation Sep 4, 2020
@trisyoungs trisyoungs added the 4 DIfficulty: 4 label Sep 4, 2020
@trisyoungs trisyoungs self-assigned this Sep 4, 2020
Copy link
Member

@DanNixon DanNixon left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good 👍 and nice to see some more testing, just some minor comments.

src/keywords/vector_is.h Outdated Show resolved Hide resolved
src/keywords/vector_is.h Outdated Show resolved Hide resolved
src/keywords/vector_is.h Outdated Show resolved Hide resolved
src/keywords/CMakeLists.txt Outdated Show resolved Hide resolved
src/keywords/vector_id.cpp Outdated Show resolved Hide resolved
src/modules/checkspecies/functions.cpp Outdated Show resolved Hide resolved
}
}
}

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There looks to be a fair bit of duplication here, can this easily be avoided?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

With a templated function and some STL magic, yes.

Sprint: September 2020 1 automation moved this from In progress to Review in progress Sep 9, 2020
Copy link
Contributor

@rprospero rprospero left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A couple of design comments, but otherwise everything looks good.

{
if (fabs(sourceParams.at(n) - refParams.at(n)) >= tolerance)
{
Messenger::print(" ... parameter {} is incorrect ({:.5e} vs. {:.5e} reference, delta = {:.5e}", n + 1,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this possibly be Messenger::error ?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I tend to use Messenger::error exclusively for syntactic, programmatic, or otherwise 'hard' errors that should stop execution at that point. When testing, I prefer to think of these 'scientific' errors separately, and so just print normal information (partly for readability reasons when looking through the system test logs).

src/modules/checkspecies/checkspecies.h Show resolved Hide resolved
src/modules/checkspecies/checkspecies.h Show resolved Hide resolved
#include <tuple>
#include <vector>

typedef std::vector<std::tuple<std::vector<int>, std::vector<double>>> IntegerDoubleVectorKeywordData;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wouldn't we be better off with std::vector<std::vector<std::tuple<int, double>>? This would ensure that there are always an equal number of integers and doubles. Or is that no desireable?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The number of integers and the number of doubles (or strings) is never guaranteed to be equal, hence the v-t-v ordering.

src/keywords/vector_intstring.h Show resolved Hide resolved
typedef std::vector<std::tuple<std::vector<int>, std::vector<std::string>>> IntegerStringVectorKeywordData;

// Keyword with list of Tuples of Vectors
class IntegerStringVectorKeyword : public KeywordData<IntegerStringVectorKeywordData &>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

After looking through the implementation classes, couldn't we have a single IntegerTVector template that takes the second type as a parameter? The code for the two classes seems identical. Or, if not a template, at least a base class that can get subclassed out for the parts that actually change?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, as I mentioned in the PR text this could no doubt be templated to some degree. In the first instance where there are only two similar classes I went for simplicity, but if a third (fourth...) derivative is required in the future then certainly we should template.

Sprint: September 2020 1 automation moved this from Review in progress to Reviewer approved Sep 14, 2020
Copy link
Member

@DanNixon DanNixon left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

@trisyoungs trisyoungs merged commit d9bae10 into develop Sep 15, 2020
Sprint: September 2020 1 automation moved this from Reviewer approved to Done Sep 15, 2020
@trisyoungs trisyoungs deleted the module-checkspecies branch September 15, 2020 08:35
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
4 DIfficulty: 4
Projects
No open projects
Development

Successfully merging this pull request may close these issues.

None yet

3 participants