Added P92 model

[siddharthlal25]

Adding P92 model, we can mention this in #10!

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 99.60%. Comparing base (a42e854) to head (aba857b).
Report is 65 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master      #29      +/-   ##
==========================================
+ Coverage   99.58%   99.60%   +0.02%     
==========================================
  Files           5        5              
  Lines         241      255      +14     
==========================================
+ Hits          240      254      +14     
  Misses          1        1              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[siddharthlal25]

@mileslucas @giordano it would be really nice if you can review this!

[mileslucas]

Also, you are missing an entry in the table in docs/src/index.md corresponding to the bibliography entry

[mileslucas]

I have some comments about whether we should restructure the P92 struct, so if we go with that there'll be some changes, but otherwise this looks good to go if you bump the minor version and fix that docstring.

[mileslucas]

I'm almost wondering if it would be easier to represent this struct hierarchically with tuples or named tuples

struct Example
	BKG = (165.0 * (1/3.08 + 1), 0.047, etc...)
    # or
    FIR = (A=0.012 * (1 / 3.08 + 1), lambda=25.0, b=0.0
end

It's clear this struct has this hierarchical order and it seems organized a little better. The question is whether this is easier for the user or if it makes sense for the user. Perhaps we don't use this for the struct itself, but we add a constructor that allows this behavior, something like

P92(BKG, FUV, NUV, SIL1, SIL2, FIR) = P92(BKG..., FUB..., NUV..., SIL1..., SILL2..., FIR...)

We could make this a kwarg-only version, but we'd have to remove the @with_kw from the struct (which is fine, we'd just have to add the assertion checking to another constructor, about the same complexity/lines-of-code)

Also, AFAIK this should have no performance impact (tuples and namedtuples are static and have lots of compiler opts.

What do you think?

[siddharthlal25]

Your point is correct, that would make the struct quite organized, but let's think from the user's perspective who is trying to switch from DustExtinction (python) to this place, things like this could be intimidating to the user. What do you think?

[mileslucas]

We can have both. The user isn't necessarily going to interact with the struct directlyy, just with the constructors and the methods. We can organize the struct however we want and organize the constructors however we want. It may be easier to not worry about it

[mileslucas]

You'll want to show that these are keyword arguments with the semicolon

    P92(; BKG_amp=218.57,

(and propagate the spacing).

[siddharthlal25]

Sorry, I clicked on resolved by mistake. 😅