Menu
▾
▴
[Jmol-developers] [ jmol-Feature Requests-2975200 ] Accept NBO PLOT format
|
From: SourceForge.net <no...@so...> - 2010-03-23 22:00:59
|
Feature Requests item #2975200, was opened at 2010-03-23 23:14 Message generated for change (Comment added) made by ghermitage You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=379136&aid=2975200&group_id=23629 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: New IO Format Group: None Status: Open Priority: 5 Private: No Submitted By: Granger Hermitage (ghermitage) Assigned to: Nobody/Anonymous (nobody) Summary: Accept NBO PLOT format Initial Comment: Actually, there is a neater way to visualize Natural Bond Orbitals than I asked for in feature request 2974999. When PLOT (it has no subparameters) is specified in the NBO parameter list, all files needed for visualization are produced. The NBO parameter list ($NBO ... $END) appears in the electronic structure system input if NBO is embedded in the ESS, and appears in the .47 input file to GenNBO if NBO is being run standalone. $NBO AONBO=P $END is not necessary, for $NBO PLOT $END will output what is needed for visualization of all natural orbital types not just NBO in AO basis. Indeed, PNBO (prenormalized NBO) may be more useful for visualization of overlaps than NBO. PLOT causes the generation of these file types: molname.31 AO molname.32 PNAO molname.33 NAO molname.34 PNHO molname.35 NHO molname.36 PNBO molname.37 NBO molname.38 PNLMO molname.39 NLMO molname.40 MO molname.41 AO density matrix molname.46 Basis label file Regardless of what ESS NBO 5 is imbedded in or what ESS GenNBO 5 derives its input from the format of these files is unchanged, so this is a completely uniform input for natural orbital visualization. Also, these inputs make a visualization tool fully functional for all natural orbital types. Also, all these types of natural orbitals (including PNBO) are available in a machine oriented format rather than having to be picked out of various places in a somewhat more human oriented format of an ESS log or output file or nbo output file (.nbo). Also, the formats .31 .. .41, .46 could be expected to be more stable across NBO updates than that of log files that might see modification in the interests of human readability. The .31 file must be present for visualization as it contains such good things as atomic number. The different types of natural orbitals are useful depending on what is being investigated. The thing to do would be to supply a directoryname/molname and let all the .31-.41,.46 be loaded with a single command, then specify what basis you wanted to be working in at that moment. I will attach a zipped sample file of each file type, though the .33 file might have to be compressed with another method, say zipx, to get under the upload limit. I can imagine Jmol quite rapidly becoming the best tool to visualize natural orbitals. ---------------------------------------------------------------------- Comment By: Granger Hermitage (ghermitage) Date: 2010-03-24 08:30 Message: 14_a_b3lyp.nbo.zip (GenNBO output) and 14_a.log.zip (Gaussian 03 output) uploaded, 14_a_b3lyp.33.zip sent. ---------------------------------------------------------------------- Comment By: Bob Hanson (hansonr) Date: 2010-03-24 04:42 Message: OK, Jmol is now reading the .nbo file and .31-.41 files. At least, provisionally. No orbitals yet, because I don't have any idea what the format of those files is. I'll need the .nbo output file for 14a, please. Also, if this comes from an ESS calc, can you please send me the ESS output file as well, showing the AO basis functions used? This will allow me to verify the file reading. Thanks Thanks. ---------------------------------------------------------------------- Comment By: Bob Hanson (hansonr) Date: 2010-03-24 04:05 Message: OK. We could do that. Where is the description of the .31 file? Bob ---------------------------------------------------------------------- Comment By: Granger Hermitage (ghermitage) Date: 2010-03-24 02:22 Message: It would be okay to load one file in the range .32 to .40 at a time For files .32 to .40 as .yy : load "molname.yy" this load could get the molname.31 and molname.46 behind the scenes. A visualization session most often (perhaps always) compares and contrasts orbitals of the same type e.g. orbitals appearing in just one type in the range .32 .. .40 Files .32 to .40 are likely to be of the same format, so code for one should work for all. A visualization tool isn't aware of the difference in meaning of orbital type. ---------------------------------------------------------------------- Comment By: Bob Hanson (hansonr) Date: 2010-03-24 00:54 Message: More thoughts. What do you think of using the OUT file as the file that is indicated (or dragged) to read. Then, if the information such as AO Basis is missing, because this is NOT part of an ESS output, then we have Jmol automatically look for and load the .31 file. And if certain FILTER options are given (which we would agree upon), then it will also read another .NN file. Could be something like load "xxx.nbo" FILTER "PNBO" load "xxx.nbo" FILTER "PNLMO" That could work. The reader would know then to go grab the data in whichever file is appropriate. Bob ---------------------------------------------------------------------- Comment By: Bob Hanson (hansonr) Date: 2010-03-24 00:25 Message: I can't decompress the 33 file. (gzip would work) -- you can send that to ha...@st... directly if you want. We can look into this as a long-term project. It would be a pretty big job that would need quite a bit more information to create a totally new reader for these. While I appreciate the fact that it adds capabilities that the ESS programs don't have, I would have to think hard about how to implement this properly considering the complexity of having all those files to worry about. OK, there are two possibilities. We do also read Spartan directories, so the idea of reading a directory or reading a zip file with included files is possible, but it relies on Jmol first reading ALL the files and then parsing the concatenated script. It's really not ideal with these big files. In principle that could be adapted a bit. Jmol does not use file extensions for identifying files, so it's a bit problematic to think about doing this just from a list of file names. For example, you can drag and drop into Jmol, but that doesn't work if you want a specific SET of files. By the way, where are the energies stored? Or doesn't that apply in the case of NBOs? ---------------------------------------------------------------------- Comment By: Bob Hanson (hansonr) Date: 2010-03-23 23:27 Message: ok, I will look at that. Not sure that's exactly "easier"! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=379136&aid=2975200&group_id=23629 |