Post subject: Problems with Hueckel Analysis HMO calculations
Posted: Mon Feb 18, 2008 10:35 pm
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.
Post subject: Why localization energies only for aromatic systems ?
Posted: Mon Feb 25, 2008 9:46 pm
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.
Post subject: Description of HMO calculation options
Posted: Tue Feb 26, 2008 8:21 pm
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.
Post subject: More problems with hetero atom systems
Posted: Mon Mar 10, 2008 5:25 pm
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.
Last edited by HUWagner on Wed Apr 30, 2008 8:08 pm; edited 2 times in total
Post subject: Problems with the pi charge density in aza systems
Posted: Mon Mar 10, 2008 5:55 pm
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.
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.
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.
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
Jozsi
Joined: 25 May 2004
Posts: 270
ChemAxon personnel
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.
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
Jozsi
Joined: 25 May 2004
Posts: 270
ChemAxon personnel
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.
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
Zsolt
Joined: 11 Jan 2006
Posts: 446
ChemAxon personnel
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.
Post subject: 4 problems in HMO calculations now solved
Posted: Wed Apr 30, 2008 8:48 pm
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.
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.
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.
Post subject: Description of HMO calculation options
Posted: Tue May 20, 2008 3:42 pm
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".
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 ?
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 <i|h|ih> 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:
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?
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).
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 .
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 .
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
Zsolt
Joined: 11 Jan 2006
Posts: 446
ChemAxon personnel
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.
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.
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.
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum You cannot attach files in this forum You can download files in this forum
FAQ
Search
Digests
Register (required to post and download)
