Menu ▾ ▴

#616 Molden File with Carthesian D and spherical F base functions

v14
open
nobody
None
5
2020-10-27
2020-10-26
srtlg
No

The MoldenReader.java contains a wrong assumption around line 371

      if (orbitalType.equals("") && data.size() < nCoef) {
        Logger.info("too few orbital coefficients for 6D");
        checkOrbitalType("[5D]");
      }

This fails for the attached example since these section markers 5D, 7F etc. can appear also at the end of the file, as generated by Q-Chem. As far as I understand the code, it is one-pass, right?
Maybe better that assuming something which causes an error at a different location, is to actually inform when an orbital type section marker is found after the MO section is parsed?

2 Attachments
cu2.molden
cu2.out

Related

Bugs: #616

Discussion

  • Bob Hanson

    Bob Hanson - 2020-10-26

    What a royal pain! OK....

     
    alternate

    • Bob Hanson

      Bob Hanson - 2020-10-26

      This is fixed. Will be in Jmol 14.31.13

      On Mon, Oct 26, 2020 at 3:22 PM Bob Hanson hansonr@users.sourceforge.net
      wrote:

      What a royal pain! OK....

      Status: open
      Group: v14
      Created: Mon Oct 26, 2020 07:48 PM UTC by srtlg
      Last Updated: Mon Oct 26, 2020 07:48 PM UTC
      Owner: nobody
      Attachments:

      The MoldenReader.java contains a wrong assumption around line 371

        if (orbitalType.equals("") && data.size() < nCoef) {
    Logger.info("too few orbital coefficients for 6D");
    checkOrbitalType("[5D]");
  }

      This fails for the attached example since these section markers 5D, 7F
      etc. can appear also at the end of the file, as generated by Q-Chem. As far
      as I understand the code, it is one-pass, right?
      Maybe better that assuming something which causes an error at a different
      location, is to actually inform when an orbital type section marker is
      found after the MO section is parsed?

      Sent from sourceforge.net because you indicated interest in
      https://sourceforge.net/p/jmol/bugs/616/

      To unsubscribe from further messages, please visit
      https://sourceforge.net/auth/subscriptions/

      --
      Robert M. Hanson
      Professor of Chemistry
      St. Olaf College
      Northfield, MN
      http://www.stolaf.edu/people/hansonr

      If nature does not answer first what we want,
      it is better to take what answer we get.

      -- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900

      We stand on the homelands of the Wahpekute Band of the Dakota Nation. We
      honor with gratitude the people who have stewarded the land throughout the
      generations and their ongoing contributions to this region. We acknowledge
      the ongoing injustices that we have committed against the Dakota Nation,
      and we wish to interrupt this legacy, beginning with acts of healing and
      honest storytelling about this place.

       

      Related

      Bugs: #616

      alternate

      • Bob Hanson

        Bob Hanson - 2020-10-27

        I'll get this released, but I am seeing an integration problem with Molden
        orbitals that we need to address.

        On Mon, Oct 26, 2020 at 6:30 PM Bob Hanson hansonr@users.sourceforge.net
        wrote:

        This is fixed. Will be in Jmol 14.31.13

        On Mon, Oct 26, 2020 at 3:22 PM Bob Hanson hansonr@users.sourceforge.net
        wrote:

        What a royal pain! OK....

        Status: open
        Group: v14
        Created: Mon Oct 26, 2020 07:48 PM UTC by srtlg
        Last Updated: Mon Oct 26, 2020 07:48 PM UTC
        Owner: nobody
        Attachments:

        The MoldenReader.java contains a wrong assumption around line 371

        if (orbitalType.equals("") && data.size() < nCoef) {
        Logger.info("too few orbital coefficients for 6D");
        checkOrbitalType("[5D]");
        }

        This fails for the attached example since these section markers 5D, 7F
        etc. can appear also at the end of the file, as generated by Q-Chem. As far
        as I understand the code, it is one-pass, right?
        Maybe better that assuming something which causes an error at a different
        location, is to actually inform when an orbital type section marker is
        found after the MO section is parsed?

        Sent from sourceforge.net because you indicated interest in
        https://sourceforge.net/p/jmol/bugs/616/

        To unsubscribe from further messages, please visit
        https://sourceforge.net/auth/subscriptions/

        --
        Robert M. Hanson
        Professor of Chemistry
        St. Olaf College
        Northfield, MN
        http://www.stolaf.edu/people/hansonr

        If nature does not answer first what we want,
        it is better to take what answer we get.

        -- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900

        We stand on the homelands of the Wahpekute Band of the Dakota Nation. We
        honor with gratitude the people who have stewarded the land throughout the
        generations and their ongoing contributions to this region. We acknowledge
        the ongoing injustices that we have committed against the Dakota Nation,
        and we wish to interrupt this legacy, beginning with acts of healing and
        honest storytelling about this place.

        Status: open
        Group: v14
        Created: Mon Oct 26, 2020 07:48 PM UTC by srtlg
        Last Updated: Mon Oct 26, 2020 07:48 PM UTC
        Owner: nobody
        Attachments:

        The MoldenReader.java contains a wrong assumption around line 371

          if (orbitalType.equals("") && data.size() < nCoef) {
    Logger.info("too few orbital coefficients for 6D");
    checkOrbitalType("[5D]");
  }

        This fails for the attached example since these section markers 5D, 7F
        etc. can appear also at the end of the file, as generated by Q-Chem. As far
        as I understand the code, it is one-pass, right?
        Maybe better that assuming something which causes an error at a different
        location, is to actually inform when an orbital type section marker is
        found after the MO section is parsed?

        Sent from sourceforge.net because you indicated interest in
        https://sourceforge.net/p/jmol/bugs/616/

        To unsubscribe from further messages, please visit
        https://sourceforge.net/auth/subscriptions/

        --
        Robert M. Hanson
        Professor of Chemistry
        St. Olaf College
        Northfield, MN
        http://www.stolaf.edu/people/hansonr

        If nature does not answer first what we want,
        it is better to take what answer we get.

        -- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900

        We stand on the homelands of the Wahpekute Band of the Dakota Nation. We
        honor with gratitude the people who have stewarded the land throughout the
        generations and their ongoing contributions to this region. We acknowledge
        the ongoing injustices that we have committed against the Dakota Nation,
        and we wish to interrupt this legacy, beginning with acts of healing and
        honest storytelling about this place.

         

        Related

        Bugs: #616

        alternate

        • srtlg

          srtlg - 2020-10-27

          Thank, you for the quick response. For the time being, I moved the 7F before the MO section. I was more concerned with the misleading error this caused.

          BTW. What repository are you using? The subversion one on sourceforge did not change.

           

          • Bob Hanson

            Bob Hanson - 2020-10-28

            I have not pushed yet.

            On Tue, Oct 27, 2020 at 2:33 PM srtlg srtlg@users.sourceforge.net wrote:

            Thank, you for the quick response. For the time being, I moved the 7F
            before the MO section. I was more concerned with the misleading error this
            caused.

            BTW. What repository are you using? The subversion one on sourceforge did
            not change.

            Status: open
            Group: v14
            Created: Mon Oct 26, 2020 07:48 PM UTC by srtlg
            Last Updated: Mon Oct 26, 2020 07:48 PM UTC
            Owner: nobody
            Attachments:

            The MoldenReader.java contains a wrong assumption around line 371

              if (orbitalType.equals("") && data.size() < nCoef) {
    Logger.info("too few orbital coefficients for 6D");
    checkOrbitalType("[5D]");
  }

            This fails for the attached example since these section markers 5D, 7F
            etc. can appear also at the end of the file, as generated by Q-Chem. As far
            as I understand the code, it is one-pass, right?
            Maybe better that assuming something which causes an error at a different
            location, is to actually inform when an orbital type section marker is
            found after the MO section is parsed?

            Sent from sourceforge.net because you indicated interest in
            https://sourceforge.net/p/jmol/bugs/616/

            To unsubscribe from further messages, please visit
            https://sourceforge.net/auth/subscriptions/

            --
            Robert M. Hanson
            Professor of Chemistry
            St. Olaf College
            Northfield, MN
            http://www.stolaf.edu/people/hansonr

            If nature does not answer first what we want,
            it is better to take what answer we get.

            -- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900

            We stand on the homelands of the Wahpekute Band of the Dakota Nation. We
            honor with gratitude the people who have stewarded the land throughout the
            generations and their ongoing contributions to this region. We acknowledge
            the ongoing injustices that we have committed against the Dakota Nation,
            and we wish to interrupt this legacy, beginning with acts of healing and
            honest storytelling about this place.

             

            Related

            Bugs: #616

            alternate

Log in to post a comment.