The value r is just a number and doesn't explicitly store or encode any point coordinates. In a signature, r is set to the X coordinate of the point R, which is really k*G, where k is the secret nonce used during signing, then reduced mod the curve order.
In secp256k1, this usually means that r is in fact the X coordinate (because r itself is usually very big), but it is not always so.
During verification, the verifier attempts to reconstruct the original R point by from the signature values (s, r), the message z and the signer's public key P by solving the equation s*R' = z*G + r*P, then reduce the X coordinate of R' mod the curve order and check that it is equal to r given in the signature.
I've never used openssl, but the process seems to be in ossl_ecdsa_verify_sig(). So you can see R' being computed here :
https://github.com/openssl/openssl/blob/master/crypto/ec/ecdsa_ossl.c#L396-L404
After these lines, the reduction mod the order is done and finally the equality test. In simple signature verification, the Y coordinate of R' is not used, but it is available from the value point (which is R') in openssl's implementation.
edit:
Also, I just realized I should add a something about pubkey recovery since you mention the v or recid value in your question.
When doing pubkey recovery from message and signature (as in the case when the signer's pukey is not given), to get the Y coordinate from a possible R' point, you would try a few values based on r as the candidate X coordinates.
The possible X coordinates of R' will be r itself, or r + curve_order (and both can be valid X's). You can then solve the curve's equation y^2 = x^3 + 7 to get the possible Y values for each.