[azmanam]

Okay, so since I have been back at work I decided to try it out with one of my more difficult peaks. This is one on an aromatic ring adjacent to two other protons, and exhibits different J coupling to each, as well as coupling to another proton one more carbon along the ring. I can see visually that this is a ddd, albeit a slightly tricky one due some overlapping peaks (though it is resolved perfectly well enough to see all of the ddd peaks), however, the program has assigned this simply as a multiplet. This is what I was asking about in my previous question. If I tell it that there are two neighbouring protons, it tells me it is a dq, which it most definitely is not. It seems that it is not so good where there is overlapping peaks of this nature, or perhaps it is struggling with the additional coupling I get from the more distant proton in the ring?

@hypervalent_iodine I'm sorry to hear about your struggles. It sounds like you're frustrated that your ddd peak is being misinterpreted by the formatter? Would you be willing to share a screen shot of the signal and it's peaks? I don't need the whole spectrum, just that signal so I can play around with it a bit. Also, you say you tell the interpreter you have 2 neighbors (which makes sense for an aromatic ring), yet a ddd has 3 j-values, and a dq has 4 neighbors (though only 2 j-values). Just clarifying how you're inputting the data into the form vs the result it's giving back to you.

Thanks for helping me field test the WebApp. I can't make it better if I don't know where it falters!

[azmanam]

Have you tried putting in '3' as # of neighbors? I know there's not really 3, but the question is more asking 'how many j-values.'

Also, have you tried leaving # neighbors as 'unknown,' and seeing what is responds with?

[hypervalent_iodine]

My point was -- did  MestreNova perform the task better than the WebAp for the substance you cited as a problem.
I assume you can do the problem very well by hand (actually brain).

Sorry, I must have missed the underlying question. Late night posting is never a good idea. I'll put it through ACD and / or MestreNova later and have a look.

[billnotgatez]

@hypervalent_iodine
I am sorry that I was not clear as I could be
I was trying to point out that the other software that is available might not be any better at figuring out your compound of interest.
It might be that you and @azmanam may make his WebApp better than others.

My point was -- did  MestreNova perform the task better than the WebAp for the substance you cited as a problem.
I assume you can do the problem very well by hand (actually brain).

Sorry, I must have missed the underlying question. Late night posting is never a good idea. I'll put it through ACD and / or MestreNova later and have a look.

[hypervalent_iodine]

@hypervalent_iodine
I am sorry that I was not clear as I could be
I was trying to point out that the other software that is available might not be any better at figuring out your compound of interest.
It might be that you and @azmanam may make his WebApp better than others.

My point was -- did  MestreNova perform the task better than the WebAp for the substance you cited as a problem.
I assume you can do the problem very well by hand (actually brain).

Sorry, I must have missed the underlying question. Late night posting is never a good idea. I'll put it through ACD and / or MestreNova later and have a look.

Yes, I see what you were getting at. I just had a look, and MestreNova determined the splitting and coupling constant of the peak just fine. Haven't looked at ACD.

[hypervalent_iodine]

Have you tried putting in '3' as # of neighbors? I know there's not really 3, but the question is more asking 'how many j-values.'

Also, have you tried leaving # neighbors as 'unknown,' and seeing what is responds with?

I tried listing as unknown first, then tried two. Trying three does allow it to identify the peak as a ddd, however the coupling constants are not correct. The app gives this:

1H NMR (700 MHz, CD3COCD3): δ 7.53 (ddd, J = 1.2, 6.9, 8.5 Hz, 1H)

Whereas MestReNova gives this:

1H NMR (700 MHz, CD3COCD3): δ 7.53 (ddd, J = 8.1, 7.3, 1.6 Hz, 1H)

When I calculate by hand, I get the same numbers as MestReNova. I wonder if maybe it isn't identifying where the doublets actually are in the middle peak, since they overlap.

@hypervalent_iodine I'm sorry to hear about your struggles. It sounds like you're frustrated that your ddd peak is being misinterpreted by the formatter? Would you be willing to share a screen shot of the signal and it's peaks? I don't need the whole spectrum, just that signal so I can play around with it a bit. Also, you say you tell the interpreter you have 2 neighbors (which makes sense for an aromatic ring), yet a ddd has 3 j-values, and a dq has 4 neighbors (though only 2 j-values). Just clarifying how you're inputting the data into the form vs the result it's giving back to you.

Thanks for helping me field test the WebApp. I can't make it better if I don't know where it falters!

This is it.

I'm not especially frustrated by anything. As I say, I prefer to do these by hand anyway. As well, my university gives me a licence for MestReNova, which can process spectra and give me nice, formatted spectral data (inc. coupling constants) within about 30 seconds, not including anything I have to add or change manually. I specified two neighbours in one run through (but usually I just said unknown) because it only has two neighbours, but it experiences longer range coupling to another proton one more carbon along the ring.

Edit: Just so you know what I input into your app, these are the ppms given on Topspin:

7.5432, 7.5409, 7.5328, 7.5317, 7.5305, 7.5295, 7.5211, 7.5189

[azmanam]

FIXED!!!

(I love this stuff. It's so much fun to dig into the what's and why's and figure out what's going on!)

First, thanks for bringing this to my attention. I greatly appreciate it.

Second, a bit about how the code works. If you work through the 2002 Hoye paper, it instructs you that peak {1 to 2} is j1, {1 to 3} is j2, then you add those together to eliminate the next peak out and so on until you identify all the j-values. But that's only half true. for even a simple dd, j1 is not only {1 to 2} but also {3 to 4}, and those should (in theory) have the same j-value. j2 is not only {1 to 3} but also {2 to 4}.

So my web app takes that into consideration, calculates both {1 to 2} and {3 to 4} for a dd, then averages them for the output for j1. Same for j2. That's fine for a dd where there is no amibguity. But for an 8-peak ddd, there is some ambiguity. There are two possible ways an 8-peak ddd could occur:



Notice that this follows Hoye's guidelines. J1 is {a-b}, J2 is {a-c}, and J3 is either {a-d} or {a-e} depending on the overlap or non-overlap of the central peaks. My code erroneously neglected to account for the potential overlap of the central peaks So my code was averaging {a-b} {c-d} {e-f} AND {g-h} when really those middle two could be swapped, and it's not trivial to tell just by looking if the central peaks overlap or not. But even though some of the pairs are ambiguous, some are retained in both sets. I should be using these to calculate the j-values, not all possible pairs.

Calculating ALL the splitting out by hand shows that even though all j1s should be the same, they are not. Note the second example (original wrong WebApp version) where assuming no central peak overlap matches the old WebApp output of 1.2, 6.9, and 8.5:



So now, the WebApp ignores the ambiguous pairs and only averages the pairs that are retained no matter the central peak overlap possibility. It also now matches the actual output of 1.6, 7.3, and 8.1.

Here's the WebApp after update showing the correct analysis of 1.6, 7.3, and 8.1:



Thanks again for all your assistance!

[hypervalent_iodine]

That's great. I had suspected that was what was happening. Glad I could *delete me*