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

An update of skdef dictionary does not update OnecenterParameters and TwocenterParameters fields #67

Closed
samtsevich opened this issue Oct 26, 2023 · 1 comment
Assignees

Comments

@samtsevich
Copy link

Describe the bug

The problem appears when I manually set the path to the config file.
This means skprogs first reads the default skdef.hsd file and then reads another, let's say, my_skdef.hsd file.
The next step is an update of Skdef dictionary by another dictionary made from my_skdef.hsd.
However, during this update, only the atomparamters field is updating, but not OnecenterParameters and not TwocenterParameters.

All of the written above can be easily fixed below this line

If that was made on purpose, please, let me know why that was made in a such way.

@samtsevich samtsevich changed the title Update skdef dictionary does not update OnecenterParameters and TwocenterParameters fields An update of skdef dictionary does not update OnecenterParameters and TwocenterParameters fields Nov 1, 2023
@aradi aradi self-assigned this Nov 15, 2023
@vanderhe
Copy link
Member

Hi @samtsevich Artem,

you are right, the fact that ./skdef.hsd is always parsed is counterintuitive. Additionally, as you correctly pointed out, the update mechanism in the backend is broken and has probably never been finalized due to difficulties in the implementation process. I created PR #70 that lifts the restriction of requiring ./skdef.hsd to be present regardless of the user input and further disables the feature of reading in multiple configuration files, at least as long as the backend has not caught up.

The motivation of having the freedom to parse multiple config files in the first place is rooted in the possible parametrization task of extending an existing set like mio-1-1 by e.g. titanium as for the tiorg mio-extension. In that case it could be handy to provide mio-related information in a separate file that is left untouched in the parametrization process.

Best regards
Tammo

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

No branches or pull requests

3 participants