Chemistry Forums for Students > Organic Chemistry Forum for Graduate Students and Professionals

WebApp to turn your NMR into publication-ready line lists. Fast, simple, easy.

<< < (5/5)

hypervalent_iodine:

--- Quote from: azmanam on January 31, 2017, 12:32:39 PM ---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?

--- End quote ---

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.


--- Quote from: azmanam on January 31, 2017, 12:15:45 PM ---@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! :)

--- End quote ---



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*

Navigation

[0] Message Index

[*] Previous page