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

Make twist attribute taking precedence over twistnum. #3799

Merged
merged 9 commits into from
Feb 4, 2022

Conversation

ye-luo
Copy link
Contributor

@ye-luo ye-luo commented Feb 2, 2022

Proposed changes

Once twist is detected, twistnum is ignored with a warning if found.
If there is only twistnum, take it and print a warning about its ambiguity.
If nothing found, set Gamma.

before the change from this PR, when both twistnum and twist are not provided, the default is twistnum=0.
This is a risky default as twistnum is risky. I made the choice to use Gamma point as the default to reduce input burden. @lshulen suggested just put an error requiring either twist or twistnum input. Let me know your choice.

Note I'm not changing tests in this PR to avoid complicating the review. They will be updated in a separate PR and it does require #3797.

What type(s) of changes does this code introduce?

  • New feature
  • Documentation changes

Does this introduce a breaking change?

  • Yes

What systems has this change been tested on?

epyc-server

Checklist

  • Yes. This PR is up to date with current the current state of 'develop'

@jtkrogel jtkrogel self-requested a review February 2, 2022 14:11
@jtkrogel
Copy link
Contributor

jtkrogel commented Feb 2, 2022

Having twist take precedence is good. In the event of no twist or twistnum, I'm OK with either twistnum=0, twist=Gamma, or abort as the default.

Giving twist precedence in the input does not need to be dependent on the resolution of the Bloch wavevector sign issue. (I misread this: the current PR does not depend on #3797).

return twist_num;
};

if (twist_inp[0] > -10 || twist_inp[1] > -10 || twist_inp[2] > -10)
Copy link
Contributor

Choose a reason for hiding this comment

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

Why was -10 chosen here?

Copy link
Contributor

Choose a reason for hiding this comment

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

Good catch. I am not for arbitrary constants. We should use clearer logic.

(I also think we should avoid the arbitrary sized buffers elsewhere in this code. It is not a good code pattern and one we should get away from.)

Copy link
Contributor Author

@ye-luo ye-luo Feb 2, 2022

Choose a reason for hiding this comment

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

The object which stores the input value needs to be initialized. So currently twistnum_inp and twist_inp are both set to -10.
I assume twistnum [-1, num_of_supertwist), twist [-1,1] as normal input.
Once the input parsing is done, value >-10 indicates input was given and actions need to be taken.
I think this should be good enough. This is different from an arbitrary grid number which gonna affect the accuracy.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Just added comments in source and commit log.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I have replaced -10 with constexpr variables.

The object which stores the input value needs to be initialized. So currently twistnum_inp and twist_inp are both set to -10.
I assume twistnum [-1, num_of_supertwist), twist [-1,1] as normal input.
Once the input parsing is done, value >-10 indicates input was given and actions need to be taken.
@ye-luo
Copy link
Contributor Author

ye-luo commented Feb 2, 2022

Test this please

@ye-luo
Copy link
Contributor Author

ye-luo commented Feb 3, 2022

Test this please

@ye-luo
Copy link
Contributor Author

ye-luo commented Feb 3, 2022

I have replace the magic numbers in the source code with constants. @jtkrogel @prckent OK to merge?

@ye-luo
Copy link
Contributor Author

ye-luo commented Feb 4, 2022

Test this please

Copy link
Contributor

@prckent prckent left a comment

Choose a reason for hiding this comment

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

Thanks for the updates

@prckent prckent merged commit 08d9943 into QMCPACK:develop Feb 4, 2022
@ye-luo ye-luo deleted the change-twist-precedence branch February 4, 2022 19:01
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants