8 Jul 2024 |
Ask Hjorth Larsen |
I guess the answer for any code here is "a reasonable mapping from Python data types to the input syntax", but then we are 90% of the way towards an ASE-specific syntax
Pretty much. What we're trying to avoid is code where right in the middle of the writer, it tries to convert Atoms into code-specific keywords, which can probably be done in a multitude of ways, while also looking up pseudopotentials and deciding the number of decimal places to print
| 16:57:14 |
9 Jul 2024 |
mjwaters | Okay, did some more digging. | 04:09:37 |
mjwaters | When is should be doing anything else like making slides, making analysis scripts, exercising, having actual fun.... | 04:10:25 |
mjwaters | but anyway | 04:10:30 |
mjwaters | https://gitlab.com/mjwaters/ase/-/blob/master/ase/calculators/vasp/create_input.py?ref_type=heads#L1228 | 04:10:31 |
mjwaters | This is how you enter 'custom' vasp tags that don't get type checked. | 04:11:03 |
mjwaters | Vasp(custom={'mytag':myvalue})
| 04:11:54 |
mjwaters | but even there the vasp calculator will fully capitalize the tag. | 04:12:53 |
mjwaters | So even If I wanted have ASE write: DRotMax = 3 in my INCAR, it will still write: "DROTMAX = 2 # <Custom ASE key>" | 04:14:46 |
mjwaters | * So even If I wanted have ASE write: DRotMax = 3 in my INCAR, it will still write:
DROTMAX = 2 # <Custom ASE key> in my INCAR | 04:15:19 |
mjwaters | Now, I would say that for VTST tags, we could wave them off as non-standard features. However, if you've ever tried doing NEB or dimer searches with the default implementation, you'll likely feel that VTST is required. | 04:18:28 |
mjwaters | Also, the VTST people are ASE people too. They have package TS-ASE, that uses ASE optimizers and classes to manage TS methods. | 04:20:54 |
mjwaters | finding a way to accommodate lower case characters seems like polite and useful idea. | 04:22:18 |
Adam Jackson | ASE already goes out of its way to include VTST keywords so yes it is clearly in-scope to make this work somehow | 06:55:36 |
Adam Jackson | although it would be a lot easier if they had stuck to VASP input conventions 😅 | 06:56:01 |
Adam Jackson | I would be inclined to solve this by delegating capitalisation of Vasp keywords to a function that explicitly checks if it is one with a non-standard capitalisation. Then the VTST "exception" is explicit in the code and it is immediately obvious why such a thing is required | 06:59:43 |
Adam Jackson | Perhaps custom keywords should also bypass this step | 07:00:49 |
Adam Jackson | That feels natural as they are explicit strings rather than kwargs | 07:01:25 |
mjwaters | In reply to @ajjackson:matrix.org Perhaps custom keywords should also bypass this step I think this is reasonable. the keyword list is so comprehensive that there's probably less than 10 people that regularly use the custom input feature. | 07:09:32 |
mjwaters | Breaking a workflows on in a tiny edge case is a good tradeoff for more flexibility. | 07:10:30 |
Adam Jackson | Then again, if any of them are VASP/VTST developers maybe it would encourage them to stay consistent 😆 | 07:10:42 |
mjwaters | Graeme Henkelman loves to talk shop, | 07:11:33 |
mjwaters | I can just email him about the issue. | 07:11:54 |
Adam Jackson | If I recall correctly, the biggest "gotcha" for vasp input writing is still that some float arguments don't allow scientific notation | 07:12:08 |
Adam Jackson | Good luck mapping that to a Python datatype 😭 | 07:12:36 |
Adam Jackson | Maybe we can use an arbitrary type annotation amd introspect it back out... | 07:13:15 |
Adam Jackson | https://docs.python.org/3/library/typing.html#typing.Annotated
sigma: Annotated[float, "no-scientific"] = ... | 07:16:50 |
Adam Jackson | (I don't remember which parameter it was, maybe sigma is ok) | 07:17:18 |
Adam Jackson | * Maybe we can use an arbitrary type annotation and introspect it back out... | 07:18:07 |
mjwaters | Honestly, the vasp input has so many overloaded tag that any vasp interface will inherently be messy with weird catches. | 07:19:14 |