Open toddkarin opened 4 years ago
There's a lot of user inertia to consider, and personally I don't see that replacing p_mp
with pmp
is needed for pvlib.
It is important to distinguish between p_mp
as a time-dependent output, and p_mp_ref
or similar as a fixed parameter as an input. I think this quantity appears in pvlib as pdc0
. Why pdc0
? Because that's the symbol used by PVWatts. pvlib tries to maintain notation from the references, although that's not a hard rule.
Yes, this change seems like a big one and it might not be worth a such a disruption just to have a slightly more elegant code. Do you imagine the variables being of the form p_mp
, p_mp_ref
, gamma_pmp
? Do we want to create single-letter lower-case abbreviations for the similar quantities: i_mp
, e_dc
(energy?), v_dc
, p_ac_a
? Or do we want a mixed bag, where we write out some of the quantities in full, e.g. power_real
, v_mp
, voltage_ac
, power_inv_ac_max
?
I'm not going to worry too much about the notation from references, since this seems like it would be necessarily outside of a unified scheme.
I'm in favor of pmp, voc, isc. I agree with @cwhanse about user inertia. For example in RdTools, we aligned things where it was a clear improvement over existing names, but in other cases decide to stick with our existing naming.
All right, which way should we go for pv-terms? At least new software will start following a convention. I would have a slight preference for p_mp
only because of greater automatic compatibility with pvlib.
I was working on some modeling with pvlib, and it uses a relatively consistent naming scheme of the form
p_mp
,v_oc
throughout. For pvterms, we decided not to use one-letter abbreviations from @bmeyers suggestion. Instead we use variables likepmp
, andpmp_ref
.I just want to double-confirm this important decision, since it seems like our new scheme is somewhat better, but will make integration with pvlib much more difficult. @cwhanse , @mdeceglie , @kanderso-nrel what do you think?