# Problems with Hueckel Analysis HMO calculations

User 25d107bd42

18-02-2008 21:35:38

The problems discussed in this long topic are solved in MarvinSketch 5.1.1

See the post at the bottom of this topic.
HUWagner, Wed Sep 24, 2008.

Hi, I still found problems in the Hueckel Calculator plugin.

As you can see in the screenshot the L(+) and L(-) localisation energies for benzene are different, these values must be equal. The difference in orbital occupation of the pentadienyl fragment concerns the third orbital which has an energy value of 0.000 beta. The right value is 2.536 beta for both localisation energies.

According to the formulas in Neil Isaacs book (page 21) the same is true for the postions 2 and 3 in methylenecyclopropene.

Regards, Hans-Ulrich

User 25d107bd42

25-02-2008 20:46:44

Hi,

getting no answer I must post the next question concerning HMO localisation energies. Why is the calculation for non-aromatic-systems blocked in MarvinSketch ?. In Neil Isaacs book the localisation energy is defined for all pi-systems and the example is methylenecyclopropene, which is neither aromatic nor an alternant hydrocarbon. The result on reactivity is very rigorous, see the attached copy.

Regards, Hans-Ulrich

User 851ac690a0

26-02-2008 10:12:10

Hi,

Thank you for the feedback.

We are going to fix the problems that you reported.

Jozsi

User 25d107bd42

26-02-2008 19:21:26

Hi,

when you are programming the Hueckel Analysis tool it would be fine to have the precise definitions, see the screenshot.

1) The calculation of the localisation energy should be possible for all pi systems (as mentioned above).

2) The pi energy should have a dimension in the display: beta

3) The expression "Pi charge density" should be replaced by "Pi electron density. This value is defined in Neil Isaacs book with this expression and it is defined as "the sum of the squares of coefficients c", and so it can not be negative as shown in the Marvin display.

4) The so called "Total charge density" can be misunderstood as sigma plus pi electron densities. It should be called Pi charge density as in Neil Isaacs book.

When can I have a prerelease version to test it ?

Regards, Hans-Ulrich

User 25d107bd42

10-03-2008 16:25:37

Hi,

getting no answer, I must post more problems with Hueckel calculations:

As you can see in the screenshot, the Marvin-value for L(-) for benzene is wrong. I have already posted this failure, see above.

But doing the same for pyridine the situation gets worse.

Obviously, the method and the hetero parameters for the aza-systems are totally different for the ring and the open chain fragments. Is it really a HMO-calculation or is it an omega-method ?

Hans-Ulrich

Mar 13, 2008, 3.00 pm. I corrected a wrong difference. HUW.

Apr 30, 2008, 9.06 pm. I omitted the screenshot containing failures. HUW.

User 25d107bd42

10-03-2008 16:55:36

Hi,

there are more problems with the hueckel calculation results:

As can be seen in the screenshot, the charge distribution in the pentadienyl cation is +1/3 at C1, C3 and C5 and -1/3 at C1, C3 and C5 in the anion. OK.

In the 3-aza-pentadienyl-cation the nitrogen in the middle is much less positively charged as the end-carbons. This could be explained by the higher electronegativity of nitrogen compared to carbon, but the effect is very heavy.

In the 3-aza-pentadienyl-anion the nitrogen in the middle is less negatively charged. This does make no sense. The nitrogen should be more negatively charged than the end-carbons, corresponding to the same argument as above, the higher electronegativity.

Hans-Ulrich

User 25d107bd42

13-03-2008 13:44:11

Hi, I have done HMO calculations using my own HMO program. For pyridine I used the standard parameters given in the three standard books A. Streitwieser Jr., E.Heilbronner and H.Bock, N.Isaacs: alfaN = alfaC+0.5 beta, betaNC = betaCC. The results, see the attachement, show me, Marvin uses the same heteroparameters for pyridine.

But using the same parameters for the localised aza-systems to calculate the localisation energies give totally different results, see the two attachements below and above this post. What method is Marvin using for calculating the aza-pentadienyl ions ?

The standard results for the localistion energies make sense for position 4 in pyridine. L(+) is larger than in benzene (see below and above), so electophilic attack is predicted to be less facile in pyridine. L(-) predicts the opposite for nucleophilic attack.

The standard parameter calculations for the aza-pentadienyl-ions give reasonable results. In the cation the most positive charges are at the ends of the chain. In the anion the most negative charge is in the middle at the more electronegative N-atom.

The Hueckel method is a qualitative method to get models for molecules and reactivities. Having the method as an applet in the web, the method should give standard results. When Marvin is using different methods, they should be documented.

User 851ac690a0

14-03-2008 12:51:17

Hi,

I fixed some bugs. Standard parameterization results in the same L(-)/L(+) values for the pyridine at the para position that you obtained with your program.

Thanks.

Jozsi

User 25d107bd42

14-03-2008 14:35:52

Hi Jozsi,

OK. Looks fine.

When do I get a pre-release to test the program further ?

I have some ideas to optimize the command line version of the HMO calculations, but this will be a new topic. And for this it would also be the best to have the newest version of Marvin.

Hans-Ulrich

User 851ac690a0

20-03-2008 12:59:40

Hi,

Bug fixed Huckel calculation will be available in the 5.0.3 version.

Unfortunately we can not include the standard Huckel calculation in the 5.0.2 version.

Jozsi

User 25d107bd42

20-03-2008 13:29:38

Hi Jozsi,

I don't understand your post. I have just downloaded the version 5.0.2 and tested the HMO calculations. Marvin 5.0.2 gives now the correct results, both for localisation energies as for pi charge densities in aza-systems, as in the standard HMO calculation with standard parameters. It gives the same values as in the correct examples above.

Regards, Hans-Ulrich

User 851ac690a0

21-03-2008 09:42:20

Hi,

Oh, yes you are right.

Yesterday we released the 5.0.2.1 version. The standard HMO calculation was excluded from this newest release because we found a serious error that is related with the modification of the HMO calculation.

We will be able to solve this error in the 5.0.3 version.

We would appreciate if you further evaluate the standard HMO method.

Jozsi

User 25d107bd42

21-03-2008 14:03:34

Hi Jozsi,

now I have 5.0.2 and 5.0.2.1 ;-)

What was the "serious error" you mentioned ?

At least for my test molecules above 5.0.2 worked fine.

Regards, Hans-Ulrich

User 25d107bd42

21-03-2008 16:21:05

Hi Jozsi, one more comment:

In this form the HMO-tool should be neither in the MarvinSketch-Applet nor in the download version. The HMO-tool should be simply blocked and deactivated until the correct version is available.

Regards, Hans-Ulrich

ChemAxon e08c317633

25-03-2008 19:40:16

Hi,

HuckelAnalysisPugin is used also in ChemAxon's Reactor application for calculating the reactivity and selectivity of some reactants/reactions, so changing the values returned by the HuckelAnalysysPugin can cause errors in Reactor.

We will solve this problem in Marvin/JChem 5.0.3.

Regards,

Zsolt

User 25d107bd42

26-03-2008 17:10:15

Hi Zsolt,

of course all applications using the HMO results are involved by the corrections.

May I mention here also my suggestion to get the eigenvalues and eigenvectors using "cxcalc huckeltable molecule", see http://www.chemaxon.com/forum/ftopic3645.html

Thank you for solving the problems.

Regards, Hans-Ulrich

ChemAxon e08c317633

28-03-2008 10:41:11

 HUWagner wrote: May I mention here also my suggestion to get the eigenvalues and eigenvectors using "cxcalc huckeltable molecule", see http://www.chemaxon.com/forum/ftopic3645.html
Hi,

OK, we will add these calculations to cxcalc in Marvin 5.1.

Regards,

Zsolt

User 25d107bd42

21-04-2008 14:15:04

Hi Zsolt,

do you think to change the descriptions of the HMO options also ?

(As I have mentioned in the forth post of this topic)

Regards, Hans-Ulrich

ChemAxon e08c317633

22-04-2008 13:14:34

Hi,

Yes, we will change them in version 5.1.

Regards,

Zsolt

User 25d107bd42

30-04-2008 19:48:48

Hi, having now Marvin 5.0.3 it looks much better:

Solved problems in Marvin 5.0.3 :-)

Summary of this topic:

1) Wrong localisation energies

-- solved

2) Why localization energies only for aromatic systems ?

-- solved

3) Problems with the pi charge density in aza systems

-- solved

4) Localisation energies for pyridine

-- solved

5) Description of HMO calculation options

-- NOT SOLVED - Will be solved in Marvin 5.1

Then we can use Marvin in HMO-Teaching.

Thanks, Hans-Ulrich

User 25d107bd42

30-04-2008 20:05:15

Hi, sorry, I have one suggestion more:

When eliminating the word "Aromatic" in the option to calculate "E(+)/Nu(-) order" it should also be possible to calculate this order for non aromatic system, such as for example fulven or hexadiene. In Marvin 5.0.3 it is not yet possible. This "E(+)/Nu(-) order" does also make sens for nonaromatic systems.

Regards, Hans-Ulrich

User 25d107bd42

06-05-2008 21:06:42

Hi, further evaluating the HÃ¼ckel calculation tools, I found a new problem with heteroatoms:

In screenshot 515 the blue values correspond to a HMO calculation done with the SHMO program using the hetero parameters alfa N = -0.5 and beta N-C = -1.0 . The so calculated L(+)energies are not the same as calculated with the Marvin tool, f. e. L(+) at C2. At C2 the blue L(+) is 1.064 and the Marvin L(+) is 0.849. The Pi Energies for the amino cation in the middle are the same, but the Pi Energies for the enamine (left) are different. Obviously the hetero parameters used for the enamine are different as for the amino cation. Why ?

In screenshot 516 the same is analysed for the electron density results.

Screenshot 517 shows the result tables of the SHMO program, showing also the hetero parameters as hX and kXY.

Regards, Hans-Ulrich

User 851ac690a0

06-05-2008 22:31:15

Hi,

The two parameters that you missed : "alpha N=0.5" and "beta N-C =0.8"

Only the "beta N-C" differs from the standard value.

With "beta N-C =1.0" I obtianed the same values than you. See attached figure.

Of course this is a bug. Because the charged and the uncharged delocalization islands were calculated with different "beta N-C" values.

I fixed this problem. The standard "beta N-C=1.0" will be used in the next release.

Jozsi

User 25d107bd42

20-05-2008 14:42:31

Hi,

coming from a student seminar using MarvinSketch I can report that the HMO calculations now work fine (Marvin 5.0.3). But there are still the failures in the option descriptions, and one must especially explain the definitions coming from the literature and the books.

And the electron density cannot be negative, see Neil Isaacs book and the screenshot547.

I posted this deficiency already Tue Feb 26, 2008 8:21 pm (see above) and I hope the descriptions will be changed in the next release.

If the description words are already used for working with cxcalc, then "pichargedensity" could be replaced by "picharge".

Regards, Hans-Ulrich

User 851ac690a0

09-06-2008 07:40:10

Hi,

Thank you for the good news.

The new release (5.1) will be available in 1-2 weeks.

Jozsi

User 25d107bd42

09-06-2008 08:04:13

Hi Jozsi,

thank you for the good news also. So I will look forward to the next release eagerly :-)

Will there also be implemented the output of the eigenvalues and eigenvectors using cxcalc huckeltable ?. I need these very much.

( http://www.chemaxon.com/forum/ftopic3645.html )

Regards, Hans-Ulrich

User 851ac690a0

09-06-2008 08:19:17

Hi Hans-Ulrich,

Yes, the eigenvalue-eigenvector output was implemented.

Jozsi

User 25d107bd42

09-06-2008 08:34:19

Thank you. Hans-Ulrich.

User 25d107bd42

28-06-2008 07:10:26

Hi Jozsi,

evaluating the new Marvin 5.0.5 I didn't find the "new HMO calculations". So I still have to wait for Marvin 5.1 ;-)

Using "cxcalc huckel" or "cxcalc hucketable" I produced the output you see in the screenshot. This was the first time I realised the decimal seperators are commas. In the GUI output there were commas also. How do you produce decimal commas with JAVA. Is there a special option, I don't know ?

In your post above ( May 06, 2008 ) I see, you are know using decimal points, as is usual in the "english dominated programming world". So I think it will be implemented in the new Marvin 5.1.

This point seems to be unimportant, but how to read the text information seen in the screenshot as input for another program ?

Regards, Hans-Ulrich

ChemAxon e08c317633

01-07-2008 14:39:41

Hi,
 HUWagner wrote: Using "cxcalc huckel" or "cxcalc hucketable" I produced the output you see in the screenshot. This was the first time I realised the decimal seperators are commas. In the GUI output there were commas also. How do you produce decimal commas with JAVA. Is there a special option, I don't know ? In your post above ( May 06, 2008 ) I see, you are know using decimal points, as is usual in the "english dominated programming world". So I think it will be implemented in the new Marvin 5.1.
It is determined by the localization settings of your OS.
 Quote: This point seems to be unimportant, but how to read the text information seen in the screenshot as input for another program ?
I suggest you to use the "-N ih" cxcalc options.

 Code: -N, --do-not-display   do not display molecule ID and/or                                  table header (in table output form):                                  i  - no molecule ID                                  h  - no table header                                  ih - neither molecule ID nor table header

Output of a "huckel" calculation with this option:

 Code: \$ cxcalc -N ih huckel "c1ccccc1" (1,1);(5,5);(4,4);(3,3);(2,2);(0,0)   (2.54,2.54);(2.54,2.54);(2.54,2.54);(2.54,2.54);(2.54,2.54);(2.54,2.54)   8.00   -1.00;-1.00;-1.00;-1.00;-1.00;-1.00   0.00;0.00;0.00;0.00;0.00;0.00

Regards,

Zsolt

User 25d107bd42

03-07-2008 14:47:11

Hi Zsolt,

now I know the reason about the decimal-komma problems: Your JAVA-Code uses the environment variable \$LANG, see the following code:

 Code: huw@tux2:~/ChemAxon505/MarvinBeans/bin\$ echo \$LANG de_DE.UTF-8 huw@tux2:~/ChemAxon505/MarvinBeans/bin\$ ./cxcalc -N ih huckel "c1ccccc1" (1,1);(5,5);(4,4);(3,3);(2,2);(0,0)     (2,54,2,54);(2,54,2,54);(2,54,2,54);(2,54,2,54);(2,54,2,54);(2,54,2,54) 8,00    -1,00;-1,00;-1,00;-1,00;-1,00;-1,00        0,00;0,00;0,00;0,00;0,00;0,00 huw@tux2:~/ChemAxon505/MarvinBeans/bin\$ export LANG=en_GB huw@tux2:~/ChemAxon505/MarvinBeans/bin\$ ./cxcalc -N ih huckel "c1ccccc1" (1,1);(5,5);(4,4);(3,3);(2,2);(0,0)     (2.54,2.54);(2.54,2.54);(2.54,2.54);(2.54,2.54);(2.54,2.54);(2.54,2.54) 8.00    -1.00;-1.00;-1.00;-1.00;-1.00;-1.00        0.00;0.00;0.00;0.00;0.00;0.00 huw@tux2:~/ChemAxon505/MarvinBeans/bin\$ echo \$LANG en_GB huw@tux2:~/ChemAxon505/MarvinBeans/bin\$ export LANG=de_DE.UTF-8 huw@tux2:~/ChemAxon505/MarvinBeans/bin\$ echo \$LANG de_DE.UTF-8

First cxcalc was running with our german default \$LANG=de_DE.UTF-8 and it is producing comma separated decimals.

Then \$LANG is changed to the english en_GB and cxcalc produces dot separated decimals (as desired).

And then we have to change \$LANG back to have the german environment.

This is absolutely impractical.

How to manage this in an heterogen environment ? I suspect the environment variable is also used in the GUI versions of the marvin programs to have the proper translations,

but on my desktop all Marvin programs "speak" english in spite of \$LANG=de_DE. \$LANG should have no influence to the output of values with decimals. Which "print-output" method are you using in your JAVA code?

Regards, Hans-Ulrich

User 25d107bd42

03-07-2008 15:07:28

Hi,

one more problem:

The E(+)/N(-) order for benzene is numbered from 0 to 5 in the command line output (see the code examples above) and from 1 to 6 in the GUI output, see the screenshot below. Why?

And by this post: I have obviously omitted the word Aromatic. Why should it be restricted to aromatic systems? (To the calculation of E(+) and N(-) you have already omitted this restriction corresponding to an early post of me).

Regards, Hans-Ulrich

User 25d107bd42

03-07-2008 15:28:48

Hi, I must add a third post:

As you can see in the screenshot I have written a little JAVA program to test the types of non-integer variables and the influence of \$LANG. I have inserted the output of the corresponding "println" commands as comment in the code.

The "accuracy" of float and double variables can be seen, especially in the middle, were a double variable is calculated coming from to float variables.

And the output is independant on the environment variable \$LANG. Thera are always dots, also in a "german" environment .

Regards, Hans-Ulrich

ChemAxon e08c317633

04-07-2008 16:14:11

 HUWagner wrote: As you can see in the screenshot I have written a little JAVA program to test the types of non-integer variables and the influence of \$LANG. I have inserted the output of the corresponding "println" commands as comment in the code. The "accuracy" of float and double variables can be seen, especially in the middle, were a double variable is calculated coming from to float variables. And the output is independant on the environment variable \$LANG. Thera are always dots, also in a "german" environment .
Please see Java Internationalization: An Overview document created by Sun Microsystems.

The relevant part:

"Numbers

What number does 1,234 represent? Of course, the answer depends on locale. In the U.S, this string of digits represents one thousand two hundred and thirty four. However, in France this represents one and two hundred thirty four one-thousandths. Significant difference? Absolutely! Imagine you're a chemical manufacturer that just received an order for 1,234 kilograms of a certain chemical. Your interpretation of this number will definitely affect your sales quotas for the month.

Numbers are represented differently around the globe. When an application shows a number to the user, it must represent that number in a way that is sensitive to the cultural expectations regarding decimal point symbol, group separators, number of digits after the decimal, and leading zeros.

The java.text.NumberFormat class performs locale-specific formatting for both general purpose numbers. To instantiate a NumberFormat object, use the factory method getInstance, which returns a NumberFormat object suitable for your default locale. You can, of course, ask for an object with a specific locale in mind. To specify a locale other than your default, use getInstance(Locale locale).

If you are curious about what locales are supported, you can use the class method getAvailableLocales. This method returns an array of Locales.

Formatting a number couldn't be easier. Call the instance methods format(long number) or format(double number) to produce a String object that's suitable for displaying to the user. Other methods allow you to customize the format by turning various options on or off."

Thanks for the feedback on this, we'll look at your concerns.

Regards,

Zsolt

ChemAxon e08c317633

04-07-2008 16:31:00

 HUWagner wrote: Hi, one more problem: The E(+)/N(-) order for benzene is numbered from 0 to 5 in the command line output (see the code examples above) and from 1 to 6 in the GUI output, see the screenshot below. Why?
The indexing of atoms in API and command line applications is started from 0. In GUI indexing is started from 1.
 Quote: And by this post: I have obviously omitted the word Aromatic. Why should it be restricted to aromatic systems? (To the calculation of E(+) and N(-) you have already omitted this restriction corresponding to an early post of me).
We will remove the aromatic restriction in Marvin 5.1.

Regards,

Zsolt

User 25d107bd42

24-09-2008 19:57:28

Hi, my compliment to the Marvin developers: The HMO-calculation problems discussed in this long topic are solved in MarvinSketch 5.1.1

Continuing the summary of Wed Apr 30, 2008

1) Wrong localisation energies -- solved

2) Why localization energies only for aromatic systems ? -- solved

3) Problems with the pi charge density in aza systems -- solved

4) Localisation energies for pyridine -- solved

there are now

5) Problem with enamin HMO parameters -- solved

6) Aromaticity restriction E(+) / Nu(-) order -- solved

7) New description "Electron density" and "Charge density" -- solved

8) Sign of electron density positive -- solved

And

9) There are now the options to calculate HMO-eigenvalues and eigenvectors using

cxcalc molecule.mrv huckeleigenvalue and cxcalc molecule.mrv huckeleigenvector

There is only one little difficulty in reading the result of these calculations, see screenshot bf0074.png. The values are seperated with commas and

in a non-american environment there is also the decimal comma (We had this discussion already above). To avoid this little problem, I suggest

to use always semicolons to seperate the different values, see screenshot bf0074semiclon.png (red semicolons).

And one further suggestion: The eigenvalues are ordered in parenthesis [..] according to the atom numbers and inside the [..] according to the vector count (= orbitals).

For the discussion of this results it makes more sense to order the eigenvectors according to the "orbitals", see screenshot bf0075.png.

The easiest way to change this would be to implement a new option "huckelorbitals" for cxcalc.

Regards, Hans-Ulrich

User 25d107bd42

25-09-2008 07:02:10

To emphasize my suggestion for implementing the option "huckelorbitals" I attach here the output of the program SHMO, showing the numbering of the triafulven and the orbitals in vertical columns.

Regards, Hans-Ulrich

User 851ac690a0

30-09-2008 13:52:17

Hi,
 Quote: To emphasize my suggestion for implementing the option "huckelorbitals"...
We are going to add this new option ASAP.

Jozsi

User 25d107bd42

30-09-2008 14:01:37

Hi,

OK. And what do you mean about the semicolons ?

Regards, Hans-Ulrich

User 851ac690a0

30-09-2008 14:27:08

Hi,
 Quote: I suggest to use always semicolons to seperate the different values, see screenshot bf0074semiclon.png (red semicolons).

Yes, you are right. We are going to correct this "bug" ASAP.

Jozsi