8000 add the CSX write support for DALTON by bwang2453 · Pull Request #249 · cclib/cclib · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

add the CSX write support for DALTON #249

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

Closed
wants to merge 5 commits into from
Closed

add the CSX write support for DALTON #249

wants to merge 5 commits into from

Conversation

bwang2453
Copy link
Contributor

This commit will allow the cclib write out the CSX file so that it could be published on the chemical semantics portal.

nocoeffs -- natural orbital coefficients (array[2])
nooccnos -- natural orbital occupation numbers (array[1])
optdone -- flags whether an optimization has converged (Boolean)
optstatus -- optimization status for each set of atomic coordinates (array[1])
package -- name of the quantum chemistry package (string)
Copy link
Member

Choose a reason for hiding this comment

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

This is superfluous - use the logname attribute.

@langner
Copy link
Member
langner commented Apr 3, 2016
8000

The introduction of basisname, package and version here is a no-go for me. We definitely don't want to create attributes for such things. If we want to parse these, however, perhaps we should create something called metadata which would be a dictionary or object and would gather such information. What do others think?

@berquist
Copy link
Member
berquist commented Apr 4, 2016

If we want to parse these, however, perhaps we should create something called metadata which would be a dictionary or object and would gather such information. What do others think?

I think a lot of this would be cleared up by the creation of an input file parser. There might still be some metadata-type attributes that it wouldn't catch (such as version), but things like the method and basis set name (the latter of which I'd like to have) would be covered in some way by an input file parser.

@langner
Copy link
Member
langner commented Apr 4, 2016

I think a lot of this would be cleared up by the creation of an input file parser. There might still be some metadata-type attributes that it wouldn't catch (such as version), but things like the method and basis set name (the latter of which I'd like to have) would be covered in some way by an input file parser.

Yes. We've been resistant to parsing/writing input files in the past, but I'm not opposed to it in principle. I think this is something we should plan for in a 2.x version, since it might involve some major changes to the API.

In the meantime, @berquist, do you think an attribute gathering metadata would be appropriate?

@bwang2453
Copy link
Contributor Author

I think it is a good idea to gather "package" and "version" into metadata, but "basisname" could be an attribute for convenience. If we are on the same page, I'll go ahead to modify the code according to it.

@langner
Copy link
Member
langner commented Apr 4, 2016

The trouble with basis set names is that they can mean different things in different programs.

@bwang2453
Copy link
Contributor Author

I have generated the metadata attribute, which currently includes "package", "version", "theory", "basisname", "spintype" and "functional".

@langner langner added this to the v1.5 milestone Apr 11, 2016
@langner
Copy link
Member
langner commented Apr 11, 2016

I like where this is going, but i think we really need to break this up further into three things:

  1. Parsing metadata/input as opposed to output data of the calculation. I also created Parsing step sizes and other parameters #260 for step size which probably also falls into this category. Whether that would entail a metadata attributes or input or something else remains to be seen.
  2. Parsing the above for DALTON and other programs
  3. Adding a CSX writer, independent of DALTON and other programs.

In any case, pushing this back to v1.5

@langner langner modified the milestones: v1.4.1, v1.5 Apr 19, 2016
@langner
Copy link
Member
langner commented Apr 19, 2016

After chatting with Bing, we decided to shoot for a v1.4.1 release as soon as we can get the CSX output support in master. We'll also include any other interesting bits that get in until then.

@langner langner modified the milestones: v1.5, v1.4.1 Jul 24, 2016
@langner
Copy link
Member
langner commented Jul 28, 2016

Note: I just noticed the earliest commits here are from before even v1.4, which means they might show up when someone uses that tag and break something. In case that happens we'll need to cherry-pick out those changes on a separate branch.

@langner
Copy link
Member
langner commented Jul 28, 2016

Closing as per @bwang2453 who will be separating issues into separate PRs.

@langner langner closed this Jul 28, 2016
@dln22
Copy link
dln22 commented May 6, 2021

After chatting with Bing, we decided 8000 to shoot for a v1.4.1 release as soon as we can get the CSX output support in master. We'll also include any other interesting bits that get in until then.

I know this is quite old, but has the CSX output support been integrated after all? I can not find this option in the most recent release.

@berquist
Copy link
Member
berquist commented May 9, 2021

@dln22 No, it was never merged. Only certain necessary pieces to support it were added. I think metadata was created as a result.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants
0