Nexus: update supported QMCPACK inputs - #6141
Conversation
|
Here is the summary referred to above: |
|
Here is the same list provided as a text file for added convenience: |
|
Are you able to get your robot to remove the unsupported tags from the actual source? That would be far more helpful :-) ( I find the list to be basically unreviewable not due to any fault of the PR or Nexus but simply that we don't know what is actually used. Obviously all the legacy stuff is headed for the wood chipper. One way to prove what is not used is to remove it. If there are any removals, unless anyone spots anything I suggest we check the full test set (more than it run in CI) and then go ahead with this good faith update. ) |
|
Here is a more complete listing of all the XML attributes, parameters and child/parent elements. At present, I think this is the closest thing we have to a complete input schema for QMCPACK. qmcpack_deep_param_search_listing.txt I also attach a file that explains the functioning within QMCPACK of each XML element and its contents (actually in rst format due to some odd upload restriction). The attributes/etc are marked as required/optional and allowed values are listed for each. Batched and legacy functionalities are listed separately. I expect this document will be helpful to reference and validate against when we update the QMCPACK manual. |
|
I've made a deeper pass revising some of the earlier assignments. Attached is a document noting the QMCPACK source file location of each non-functioning input. qmcpack_deep_unsupported_param_locations.txt I haven't taken a close look at this yet, but I plan to use it in another PR that attempts removal of these inputs. |
|
I'm not 100% sure these are completely accurate, it might be better to have the llm write a script but it did find an issue in the structure factor input. Just not 100% sure its the one implied. Between this and the deep_unsupported_param I noticed that there is disagreement in whether the attribute name is "hdf5" or "writehdf5" The input grammar as represented in the input class is "hdf5" and that is also what the test program has for valid input xml, but the class actually reads "writehdf5" if present. This is an issue with the whole |
|
Ok to avoid burying the lede: I do see many inputs marked unsupported that were never a part of the input grammar for a batched estimator input or its children. If I understand what this is about I think that is ok. So if you can tolerate false negatives i.e. something marked as unsupported that was never considering by the estimator then I see no trouble here. Ok the TLDR part: I now feel like a one to one comparison between the input class defined grammar of the new estimators and nexus needs to be done either by a human or with a deterministic tool. I think that would be a next step and would focus on removing particular inputs for particular estimators completely or the smaller possibility there could be input options that nexus doesn't know about. I've got a couple of threads to pull from the surprising unsupported inputs with respect to cleanup of input classes that don't reflect design decisions that were made later a particular port. Since the PR sequence was InputClass+Testing->Estimator+Testing->Application+Estimator+Testing I can see now that there was a couple of missing steps ReviseInputClass and UpdateNexus. |
|
I asked myself where I should be able to locate the up-to-date list of input tags as a user. My immediate answer is the user guide. However, we all know that our user-guide is not up-to-date and complete. Finding all the input parameters from the source code is an easy task by AI. Once we have a list, enforcing tests and user-guide consistency will be feasible. For example, if a class interacts with xml, corresponding unit test should be required. Not necessarily testing the feature but at least testing the input should be required. |
walkerlogs is a driver input.
input options for bspline sposet is missing. I didn't read the whole list. Quick spot checks indicate the current list in poor quality. |
|
These lists were the result of a few deep passes of the source code with AI along with cross-checks against the entire example/test/lab set of known input files as well. The aim was to connect an input tag with evidence (or not) to "live" functionality in QMCPACK. Many times the inputs were simply read and not used at all.
The categorizations of the attributes/parameters are not all exclusive. For example, Also, the |
This PR updates QMCPACK input attributes, parameters, and XML elements supported by Nexus.
Inputs that QMCPACK no longer supports (possibly read but are non-functional) are stored in a new
unsupportedcategory.At present, the added inputs are available only via direct instantiation of the related
QIxmlelements. Support for a subset of these will be added togenerate_qmcpack*functions in a later PR.Prior to merge, these inputs need to be screened for relevance: should some always be excluded? Are some that are marked non-functional/unsupported miscategorized?
Also helpful would be to note which are prominent/useful enough to surface to users at the
generatelevel in a follow-on PR.Below, I make a simple summary to aid reviewers in this process; the line-by-line changes in Nexus are less relevant than the corresponding information in this list.
Made with assistance from GPT-5.6 Sol based on the QMCPACK manual and the direct source code.