amplifier model revision

[jeanluc-auge]

Following an email exchange with @ojnas it would be more clear and pratical to separate the spectral model from the other description. Now most of the models have a default_edfa_config.json (all ripple description to 0), so it’s just a minor code change to be able to enter a custom “advanced_config_from_json” input for all models. If it’s left empty, the default config could be assumed for example. This way we could end up with just 4 models (5 with upcoming Raman):

• polynomial NF: can also be used for the fixed gain model with coef [0,0,0, NF], so the current fixed_gain model can be deprecated

type_variety
type_def: “polynomial_NF”, 
gain_flatmax
gain_min
p_max
nf_coef
spectral_info_json (optional)
out_voa_auto
allowed_for_design

• polynomial OSNR = current unchanged “openroadm” description, you may want to keep type_def: “openroadm” for clarity

type_variety
type_def: “polynomial_OSNR”
gain_flatmax
gain_min
p_max
osnr_coef
spectral_info_json (optional)
out_voa_auto
allowed_for_design

• operator_model, which is the current variable gain where you enter NF_min and NF_max instead of a polynomial. => the difference with a polynomial model is minor: you can do the test, compare the NF from the variable gain model with a polynomial curve once you have entered the NF_min and NF_max values of the polynomial range in the variable gain model. I always find < 0.5dB NF at worse (which is <0.2dB SNR at the optimum power) and most of the time <0.1dB NF difference.

type_variety
type_def: “operator_model”
gain_flatmax
gain_min
p_max
nf_min
nf_max
spectral_info_json (optional)
out_voa_auto
allowed_for_design

• dual_stage, current unchanged description, this is very handy to support dual stage configurations. It works very well for auto-design, and I have validated it with multiple import from supplier designs: it does the job. It describes a combination of any of the above models.

type_variety
type_def:”dual_stage”
gain_min (auto-design interest, don’t use below this gain)
raman (auto_design interest: true/false raman in the preamp)
preamp_variety
booster_variety
allowed_for_design

type_variety
type_def:”raman”?
pumps_power_list [p1,p2,p3…]
pumps_frequency_list [f1,f2,f3…]
…

And that’s it. For each of these models (except the dual stage of course) you just need to add an optional json input field to load the detailed spectrum information if needed.

[jktjkt]

I like this, and it seems that @ojnas likes this, too. Is someone against this proposal?

Cc: @aleFerrari

Just one thing to confirm that I understand correctly:

operator_model, which is the current variable gain where you enter NF_min and NF_max instead of a polynomial. => the difference with a polynomial model is minor: you can do the test, compare the NF from the variable gain model with a polynomial curve once you have entered the NF_min and NF_max values of the polynomial range in the variable gain model. I always find < 0.5dB NF at worse (which is <0.2dB SNR at the optimum power) and most of the time <0.1dB NF difference.

This is about a situation where we already have the polynomial, right? So this is about looking at its output, extracting the (min, max) NF, feeding that to the "operator model", and comparing output of that simulation with the original, polynomial-based one. Right?

[ggrammel]

I also like the proposal except the name "operator_model". What I like by giving the models a name is that it is immediately clear how detailed the description is supposed to be and spot if an AMP with lesser detail is used. What I dislike giving model names is that the name implies something that may not be true i.e "operator model". We certainly used this term for discussions, but to me it implies too much. It suggests that all other models are not for operators. In line with the other models I'd suggest to keep "variable_gain" or call it "linear-NF" or maybe "basic_NF" as it appears to be the most basic amplifier model to start with.

Note: looking at the parameters I now also wonder if there is sufficient need to give the 4 models a specific name. It looks like there are two basic models: a x-NF model and an x-OSNR model, whereby the Dual-Stage one is kind of a macro indirectly using those. Within the basic models it is a level of detail in the description that makes the difference.

[EstherLerouzic]

👍 +1

[jeanluc-auge]

I like this, and it seems that @ojnas likes this, too. Is someone against this proposal?

Cc: @aleFerrari

Just one thing to confirm that I understand correctly:

operator_model, which is the current variable gain where you enter NF_min and NF_max instead of a polynomial. => the difference with a polynomial model is minor: you can do the test, compare the NF from the variable gain model with a polynomial curve once you have entered the NF_min and NF_max values of the polynomial range in the variable gain model. I always find < 0.5dB NF at worse (which is <0.2dB SNR at the optimum power) and most of the time <0.1dB NF difference.

This is about a situation where we already have the polynomial, right? So this is about looking at its output, extracting the (min, max) NF, feeding that to the "operator model", and comparing output of that simulation with the original, polynomial-based one. Right?

Yes, this is exactly the right comparison to do. It used to be part of the tests, but if you check the corresponding test it doesnt' do anything anymore: broken test I guess I broke it when I changed the nf_model early last year (don't remember) => I recommend to fix this test.

[jeanluc-auge]

Thanks all for the feedback. But do not call it linear NF or basic NF: it is not linear and it is not basic. Actually it is more complicated to calculate than a polynomial. It is a 2 stages amp.

[ggrammel]

So you think that "variable_gain" would be OK? -- or is there in your view a good reason to keep the name "operator model"?

[ojnas]

I would prefer to not call it variable_gain since both the polynomial_NF and the polynomial_OSNR models could also be used to model "variable gain" EDFAs.