Updated wind perscriptions #996

jmerritt1 · 2023-09-27T02:07:46Z

Added a new UPDATED option to the mass-loss prescriptions. This is a wrapper applying new specific prescriptions on a case-by-case basis. These are selected via new program options for OB, VMS, RSG, and WR-mass-loss, which each have their own wrapper function selecting from a total of 15 new perscriptions. Previous default behavior is recoverable by specifying VINK.

Commit history is in the updated_winds branch, which became relatively unmergable. The changes have been collected and added to an up-to-date branch here as Jeff suggested.

…er merge, changes broken down with history in updated_winds

SimonStevenson · 2023-09-27T04:56:58Z

Two things that will need updating:

Update changelog.h with description of changes, and bump version
Update documentation for new options

jmerritt1 · 2023-09-27T23:12:25Z

note in Options.cpp, that we didn't use, (" + AllowedOptionValuesFormatted(" and instead list the options as before. This convention must have been changed in the last few months. See

COMPAS/src/Options.cpp

Line 1736 in fe48a6b

    
           ("OB mass loss prescription (options: [NONE, VINK2001, VINK2021, BJORKLUND2022, KRTICKA2018], default = " + p_Options->m_OBMassLoss.typeString + ")").c_str()

for example.

jeffriley · 2023-09-27T23:20:32Z

note in Options.cpp, that we didn't use, (" + AllowedOptionValuesFormatted(" and instead list the options as before. This convention must have been changed in the last few months. See

COMPAS/src/Options.cpp

Line 1736 in fe48a6b

("OB mass loss prescription (options: [NONE, VINK2001, VINK2021, BJORKLUND2022, KRTICKA2018], default = " + p_Options->m_OBMassLoss.typeString + ")").c_str()

for example.

Yeah, that changed a while ago - we should use the new method in this PR (not difficult)

…ionValuesFormatted() anyway?

jeffriley · 2023-09-27T23:39:08Z

missed one new RSG option on ln 1736, but should change to AllowedOptionValuesFormatted() anyway?

Yes - that way the help text is automatically updated if any of the allowed values are changed - and the help text format is kept uniform with other options.

VMS, RSG, WR mass loss program options

…Formatted()

jmerritt1 · 2023-09-27T23:54:18Z

missed one new RSG option on ln 1736, but should change to AllowedOptionValuesFormatted() anyway?

Yes - that way the help text is automatically updated if any of the allowed values are changed - and the help text format is kept uniform with other options.

Thanks, one less spot to change options in the future. I've updated these.

ilyamandel · 2023-09-28T13:07:12Z

Sorry, I am offline until October 8, so won't be able to review this -- defer to @jeffriley and @SimonStevenson !

jmerritt1 · 2023-09-28T20:18:07Z

Two things that will need updating:

Update changelog.h with description of changes, and bump version

Update documentation for new options

in program-options-list-defaults.rst, it's formatting some of the options lists with the bracket on the next line, but I'm not seeing why?

jeffriley · 2023-09-29T20:18:44Z

bumped version to 02.39.02

Let's make it 02.40.00 - this is new functionality, not a defect repair

xx.yy.zz -> xx is (supposed to be) major new release; yy minor new release/new functionality; zz defect repair

jmerritt1 · 2023-09-29T20:47:17Z

bumped version to 02.39.02

Let's make it 02.40.00 - this is new functionality, not a defect repair

xx.yy.zz -> xx is (supposed to be) major new release; yy minor new release/new functionality; zz defect repair

Should I list all the specific perscriptions in the changelog or are just the new program options fine?

jeffriley

Thanks @jmerritt1. I have a few comments and suggested changes. I'll number them so we can refer to them by number if necessary:

prescription is mis-typed as perscription in a few places:

program-options-list-defaults.rst
BaseStar.cpp
changelog.h
constants.h
Options.h
Should we implement an option to set the VERY_MASSIVE_MINIMUM_MASS threshold, or is 100Msol either the universally accepted threshold or required for our implementation?
If you run your version of the executable with ./compas --help, you will see:

Options:
...
--OB-mass-loss
OB mass loss prescription (Options: [], default = 'NONE)
...

Note no options listed in [] - that's because you missed step 9 in the instructions at the top of Options.cpp

Also note that there is a missing single quote after 'NONE - that needs to be added in Options::AddOptions():

Change
```
     `("OB mass loss prescription (" + AllowedOptionValuesFormatted("OB-mass-loss") + ", default = '" + p_Options->m_OBMassLoss.typeString + ")").c_str()`
```
to
```
    `("OB mass loss prescription (" + AllowedOptionValuesFormatted("OB-mass-loss") + ", default = '" + p_Options->m_OBMassLoss.typeString + "')").c_str()`
```
and similarly for RSG-mass-loss, VMS-mass-loss, and WR-mass-loss

If you run your version of the executable with ./compas --create-yaml-file myyaml, and look at the resultant yaml file (myyaml). At the bottom of the file you'll see:

 ### Additional COMPAS options not found in YAML template ###
 #    --RSG-mass-loss: 'NJ90'                                               # Default: 'NJ90'
 #    --VMS-mass-loss: 'NONE'                                               # Default: 'NONE'
 #    --WR-mass-loss: 'BELCZYNSKI2010'                                      # Default: 'BELCZYNSKI2010'
 #    --metallicity-distribution: 'ZSOLAR'                                  # Default: 'ZSOLAR'          Options: ['LOGUNIFORM','ZSOLAR']

That's because your changes to yaml.h:

     "    --OB-mass-loss: 'NONE'                                                # Default: 'NONE'"
     "    --RSG-mass-loss: 'NJ90'                                               # Default: 'NJ90'"
     "    --VMS-mass-loss: 'NONE'                                               # Default: 'NONE'"
     "    --WR-mass-loss: 'BELCZYNSKI2010'                                      # Default: 'BELCZYNSKI2010'"

are malformed. You need to remove the default values in both places. e.g. change

     "    --OB-mass-loss: 'NONE'                                                # Default: 'NONE'"

to

     "    --OB-mass-loss"

and similarly for RSG-mass-loss, VMS-mass-loss, and WR-mass-loss (see examples above and below your additions in yaml.h).

BaseStar::CalculateMassLossRateOBBjorklund2022():
- function name in description does not match actual function name
- is it worth noting the caveats documented in the description (i.e. "This prescription is calibrated to the following ranges:") in the online documentation for the relevant option? Is it important a user knows that (particularly a user who may just use COMPAS without looking at the code)?
BaseStar::CalculateMassLossRateOBVinkSander2021():
- function name in description does not match actual function name
- function has commented code that should be removed
- equations at lines 2015-2020, 2030-2035, and 2045-2051 have ragged right edges with math operators. Either have a single space between the end of the text and the operator, or line all operators up (like the equation at 1967-1973) - the way it is makes it too hard to read.
- it's easier to read if the comments at the end of code lines are aligned with each other too (for humans maintaining the code - the compiler doesn't care of course...)
BaseStar::CalculateMassLossRateOBKrticka2018():
- function name in description does not match actual function name
- log10(m_Metallicity / ZSOL) is BaseStar::LogMetallicityXi() - log10() is expensive, no need to call it if we don't have to (and twice...).
BaseStar::CalculateMassLossRateRSGBeasor2020() has commented code that should be removed.
BaseStar::CalculateMassLossRateRSGDecin2023():
- I would probably just rewrite this as:
```
 return PPOW(10.0, -20.63 - 0.16 * m_MZAMS + 3.47 * log10(m_Luminosity));
```
  but, can't we rewrite that as:
```
 return PPOW(m_Luminosity, -20.63 - 0.16 * m_MZAMS + 3.47);
```
  I think the latter would use fewer compute cycles - the former seems to do an unnecessary log10() operation, which isn't cheap.
BaseStar::CalculateMassLossRateRSGKee2021():
- has commented code that should be removed.
- also, change 2. -> 2.0, 17000. -> 17000.0, and 60000. -> 60000.0 (for the same reason as above - easier for humans to read (esp. at a glance))
BaseStar::CalculateMassLossRateRSGVinkSabhahit2023():
- change -8. -> -8.0, and -24. -> -24.0 (same as above)
BaseStar::CalculateMassLossRateVMSBestenlehner2020():
- change 1. -> 1.0 (same as above)
- change constants 1 and 2 to 1.0 and 2.0. c++ is a strongly-typed language: "1" is an integer, whereas "1.0" is a double. It may make no difference now, but it might if someone changes things later - it's good practice to use the correct data type even for constants.
BaseStar::CalculateMassLossRateVMSVink2011():
- reference/link to paper in the description (is 'Vink 2011' sufficient)?
- function should be const
- if the else clause is executed, rate is calculated, and is recalculated after the if/else using logMdotdiff which is undefined (only defined in the if clause is executed). teff and rate2001 only need to be calculated in the else clause, so those calculations should be moved into the else clause. Bring the final calculation of rate up into the if clause (it requires logMdotdiff).
BaseStar::CalculateMassLossRateVMSSabhahit2023():
- reference/link to paper in the description (is 'Sabhahit 2023' sufficient)?
- function should be const
- resolve and remove question on line 2260
BaseStar::CalculateMassLossRateWolfRayetSanderVink2020():
- change the conditional on line 2425 to use utils::Compare()
- Mdot has already been initialised to 0.0 (at line 2412), so no need to set it 0.0 at line 2426. Instead, change the conditional to
  if (utils::Compare(logL0, logL) < 0) and delete lines 2426 and 2427.
- move line 2434 into the if - no need to multiply by the option value if Mdot is 0.0 - just wastes compute cycles.
- change - 1 to - 1.0 on line 2430
BaseStar::CalculateMassLossRateVMS() has commented code that should be removed
BaseStar::CalculateMassLossRateWolfRayetTemperatureCorrectionSander2023():
- change 141E3 to 141.0E3 on line 2457 (same as above re data type)
- change 100E3 to 100.0E3 on line 2458 (same as above re data type)
- change the conditional on line 2465 to use Utils::Compare()
BaseStar::CalculateMassLossRateHeliumStarVink2017(): I think I'd just use a single return line, but up to you.
BaseStar::CalculateMassLossRateHeliumStarShenar2019() has commented code that should be removed
BaseStar::CalculateMassLossRateOB(): parameter should be const
BaseStar::CalculateMassLossRateRSG(): parameter should be const; function should be const
BaseStar::CalculateMassLossRateVMS(): function should be const
BaseStar::CalculateMassLossRateUpdatedPrescription():
- "The structure is similar to above" - do you mean similar to BaseStar::CalculateMassLossRateVink()? If so, say so (it may not be above if the code gets changed/refactored).
Add an entry to the What's New page of the online documentation to describe any changes to default behaviour (e.g. which mass loss prescription is now default? Any other changes to default behavour?)
Your question: "Should I list all the specific perscriptions in the changelog or are just the new program options fine?"
- Just the new options are fine for changelog, but you should add a more complete descripion in the 'What's New' entry (see above).
Given the number of times we use log10(m_Luminsoity), I wonder if it's worth calculating that when m_Luminosity is calculated, and storing it in a class member variable (call it m_Log10Luminosity - similar to m_Log10Metallicity)?

That's about it - there are some minor formatting changes I'll either point out later or just fix myself at the final review.

I have not checked the functionality - I checked that the code runs and data is produced, but I have not checked if the contents of the data files are correct according to the new prescriptions added, or whether any existing functionality has been negatively impacted (wrt the correctness of the data produced). I assume you have satisfied yourself that the data produced is correct.

jeffriley · 2023-10-03T05:18:43Z

And...

in program-options-list-defaults.rst, it's formatting some of the options lists with the bracket on the next line, but I'm not seeing why?

I think that's just the way Read the Docs formats - the line break just happens to be there. You could play around with the text to shift the line break away from the bracket if it really bothers you.

jeffriley · 2023-10-03T20:32:35Z

One more change:

Change

constexpr double LSOLW = 4E26;

in constants.h to

constexpr double LSOLW = 4.0E26;

jeffriley · 2023-10-03T23:25:10Z

Wait...

but, can't we rewrite that as:
return PPOW(m_Luminosity, -20.63 - 0.16 * m_MZAMS + 3.47);

No, that's wrong (I mentally put parentheses around -20.63 - 0.16 * m_MZAMS + 3.47). Can we still avoid the log10? Maybe...

…g file (dont use the method paper config)" This reverts commit 346e98d.

SimonStevenson · 2023-10-31T02:48:51Z

Thanks everyone for the input on this PR, it's great that it's almost there.

running with the new default prescription won't artificially reduce WR by an extra factor of 10?

Currently, it does reduce WR mass-loss rates by an additional factor of 10. I believe that all of JDs testing/results have been performed with this setup. I noticed this the other day. We will do some additional testing/comparisons of fWR=0.1 v fWR=1.0. I think that the new WR mass-loss prescription does not reduce mass-loss rates by as much as a factor of 10 for most high-mass He stars.

I made a plot comparing the initial-final He star masses (at solar metallicity) for both the old and new prescriptions, with fWR=0.1 and fWR=1.0.

Here we see that whilst for low-mass He stars (where we use Vink2017) the mass-loss rates are reduced, for high-mass solar metallicity He stars we actually see increased mass loss.

running with the BELCZYNSKI2010 prescription will reproduce the immediately preceding default (including that factor of 0.1)?

Currently this is not the case -- whatever value of fWR is set will be used. If the user doesn't specify a value, the default will be used (currently 0.1).

Based on this, I'm not sure what the new default fWR should be (fWR=1.0 better reflects the implemented mass-loss prescriptions, fWR=0.1 allows for the production of Cyg X-1 like BH masses at solar metallicity).

jmerritt1 · 2023-10-31T18:47:32Z

Thanks everyone for your work on this. I've been travelling for two weeks but just got back online and caught up with the discussion.

A. @jmerritt1, from your comment above:

... m_DominantMassLossRate ... It is my preference to only set this flag in higher wrapper functions ...
Can you just do a final check that m_DominantMassLossRate gets set when it should (e.g. scenario above - BaseStar::CalculateMassLossRateOBVink2001() is called from multiple places).

I've checked again that m_DominantMassLossRate is set in both the BELCZYNSKI2010 (added one missing line for OB) and FLEXIBLE2023 wrappers. For some of the giant branch specific prescriptions, it is set in the relevant stellar type files under the Hurley wrapper.

B. enum class MASS_LOSS_TYPE in constants.h somewhat confusingly mixes mass loss as applied to different types of stars (VERY_MASSIVE, RED_SUPERGIANT, LBV) with specific prescriptions (say, VINK -- Vink wrote a lot of papers about mass loss from different kinds of stars, so not clear what this refers to in this context)

I changed this list to include broader types of mass loss, and not specific prescriptions. We are leaning towards only including types, eg. RSG, VMS, etc. I agree that VINK should be removed, since it should now no longer be set in the higher level wrappers in favor of OB. NIEUWENHUIJZEN_DE_JAGER, KUDRITZKI_REIMERS, and VASSILIADIS_WOOD are sometimes set by the stellar type specific giant branch files. If distinguishing between these isn't an important diagnostic tool, we can change all these to RSG. Is there any reason we need the older prescription specific labels?

Regarding C. and fWR, I've been running with fWR=1.0 for everything so far, and hadn't realized the default .yaml had changed.

ilyamandel · 2023-10-31T23:04:41Z

@SimonStevenson -- I am trying to match up your latest plot with the one from your paper with Teagan. That one was in units of luminosity rather than mass on the abscissa -- but it seemed to show that at the highest luminosities (i.e., high masses), mass loss rates from newer models were actually below those from the old models with a rescaling factor of 0.1, right?

ilyamandel · 2023-10-31T23:06:22Z

@jmerritt1 -- I like your suggestion of removing VINK and replacing all of NIEUWENHUIJZEN_DE_JAGER, KUDRITZKI_REIMERS, and VASSILIADIS_WOOD with RSG. Thanks for doing that!

SimonStevenson · 2023-10-31T23:12:24Z

@ilyamandel We're not using Vink2017 for high-mass (high luminosity) WR stars, only for low-mass (low-luminosity) stripped He stars. At solar metallicity, the transition is around L = 10^5 Lsol (which corresponds to an initial helium star mass somewhere in the range 5-10 Msol). We are using the prescription from Sander & Vink 2020 for high-mass He stars. This results in similar mass-loss rates to the old Belczynski+2010 prescription.

ilyamandel · 2023-10-31T23:21:21Z

Thanks for the explanation, @SimonStevenson ! I wonder if we ultimately want two separate WR multiplier choices, for Vink 2017 at lower masses and for Sander & Vink 2020 at higher masses? If we did, I might be tempted to use fWRlowmass = 1 and fWRhighmass=0.1 in my runs... But I think the default should be 1 for both, since these are the best available models, and so long as we use just one multiplier, let's keep the default at 1.

BTW, does the transition happen exactly at the point where the Vink 2017 and Sander & Vink 2020 curves cross over in your plot? If not, wind mass loss rates would be discontinuous, which is a bit weird.

SimonStevenson · 2023-10-31T23:22:45Z

Yes, we just use the maximum of the two prescriptions, so the transition is where they cross over.

ilyamandel · 2023-10-31T23:31:51Z

OK, then my only two remaining requests are:

remove VINK and replace all of NIEUWENHUIJZEN_DE_JAGER, KUDRITZKI_REIMERS, and VASSILIADIS_WOOD with RSG in MASS_LOSS_TYPE (and in the code where it's assigned)
set the default Wolf-Rayet multiplier to 1.0 rather than 0.1 (and regenerate the default .yaml)

jmerritt1 · 2023-10-31T23:43:10Z

@jmerritt1 -- I like your suggestion of removing VINK and replacing all of NIEUWENHUIJZEN_DE_JAGER, KUDRITZKI_REIMERS, and VASSILIADIS_WOOD with RSG. Thanks for doing that!

Ah actually I've forgotten we will need to add a label for evolved/giant stars that are also below the cutoffs for RSG, see the pink lines (KR) in the below figure for example. (colored by dominant mass loss rate)
Also, is there any opposition to using acronyms, RSG, LBV, in place of full labels, since this is mainly a diagnostic tool?

jmerritt1 · 2023-10-31T23:44:57Z

And in the above figure, just want to make sure that this is the intended treatment for the gap between 12.5kK and 8kK, around HG, Simon and I came to the understanding that you'd like these to be treated as WR (see short purple line segments around HG)? We revisited the original conversation with Andreas Sander and this seems to be the intention?

ilyamandel · 2023-11-01T00:02:42Z

Looks great!

…

On Wed, 1 Nov 2023, 12:43 am jmerritt1, ***@***.***> wrote: @jmerritt1 <https://github.com/jmerritt1> -- I like your suggestion of removing VINK and replacing all of NIEUWENHUIJZEN_DE_JAGER, KUDRITZKI_REIMERS, and VASSILIADIS_WOOD with RSG. Thanks for doing that! Ah actually I've forgotten we will need to add a label for evolved/giant stars that are also below the cutoffs for RSG, see the pink lines (KR) in the below figure for example. Also, is there any opposition to using acronyms, RSG, LBV, in place of full labels, since this is mainly a diagnostic tool? [image: image] <https://user-images.githubusercontent.com/45217727/279538596-3cf765ae-f2f2-4f1c-ab57-0e09341a2e0d.png> — Reply to this email directly, view it on GitHub <#996 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAD5BVJBFP7WQPXNUO7ZKJTYCGEJVAVCNFSM6AAAAAA5ITJLVGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTOOBYGE4DENRXGI> . You are receiving this because you were mentioned.Message ID: ***@***.***>

jeffriley · 2023-11-01T00:31:05Z

and regenerate the default .yaml

Just in case you missed it, there's now an option to do that (--create-yaml-file, see https://compas.readthedocs.io/en/latest/pages/User%20guide/Program%20options/program-options-list-defaults.html#options-props-c)

jmerritt1 · 2023-11-01T00:38:15Z

and regenerate the default .yaml

Just in case you missed it, there's now an option to do that (--create-yaml-file, see https://compas.readthedocs.io/en/latest/pages/User%20guide/Program%20options/program-options-list-defaults.html#options-props-c)

Just tried this but have it writing the previous default, fWR=0.1. Where should I change this? options.cpp? (edit, just wasn't working because I forgot to recompile before generating).

jeffriley · 2023-11-01T03:12:25Z

@jmerritt1 I don't think you pushed the new version of Options.cpp - with m_WolfRayetFactor = 1.0

Oh - and compasDefaultConfig.yaml should be in compas_python_utils/preprocessing, not src

jmerritt1 · 2023-11-01T18:29:36Z

@jmerritt1 I don't think you pushed the new version of Options.cpp - with m_WolfRayetFactor = 1.0

Oh - and compasDefaultConfig.yaml should be in compas_python_utils/preprocessing, not src

Okay I think it's fixed now, and I've removed the one in src.

…alue

Made LSOL and LSOLW consistent

ilyamandel

Looks good -- thanks for all the hard work, everyone!

ilyamandel · 2023-11-14T19:23:38Z

@jmerritt1 -- I saw your new issue post via e-mail, but it seems to have disappeared. I suggest posting new issues separately, since people will likely miss them in closed PRs.

Updated wind perscriptions

* Fix for issue #1022 * Code cleanup * Event strings (#1021) * (compasUtils) bug fix to getSNevents() * (compasUtils) make getEventHistory() work for COMPAS output with unordered seeds * (compasUtils) fix typo * switched to lexsort from argsort to better handle the ordering of multiple events from the same seed * changed list initialization for np array, changed some variable names for clarity * changed np array back to list, since array couldn't handle input of different sizes --------- Co-authored-by: Reinhold Willcox <[email protected]> * Merge pull request #996 from TeamCOMPAS/updated_winds_fresh Updated wind perscriptions * Reapply winds changes from 2.40.00 * fixes to the detailed plotter, including improved robustness to the Roche Lobe, and masking for only end-of-timestep events * added question to CalculateMassLossRateNieuwenhuijzenDeJager --------- Co-authored-by: Jeff Riley <[email protected]> Co-authored-by: Ilya Mandel <[email protected]> Co-authored-by: Mike Lau <[email protected]> Co-authored-by: jeffriley <[email protected]>

manually added all our changes to a new up-to-date branch for a simpl…

fe48a6b

…er merge, changes broken down with history in updated_winds

jmerritt1 requested review from ilyamandel, SimonStevenson and jeffriley September 27, 2023 02:07

SimonStevenson added the enhancement New feature or request label Sep 27, 2023

missed one new RSG option on ln 1736, but should change to AllowedOpt…

b57c749

…ionValuesFormatted() anyway?

Jonathan Merritt added 2 commits September 27, 2023 16:44

updated docs with OB,

539e0ce

VMS, RSG, WR mass loss program options

Changed OB, VMS, RSG, WR mass loss options to use AllowedOptionValues…

155399d

…Formatted()

Jonathan Merritt added 2 commits September 29, 2023 10:20

added OB, RSG, VMS, WR mass loss options to yaml.h

d1ea6bb

added Enhancement description to changelog, bumped version to 02.39.02

38b7d2f

bumped version to 02.40.00

fc749b6

jeffriley requested changes Oct 3, 2023

View reviewed changes

added YHe as an exception, to pass the precommit spelling check

5ff6a44

Jonathan Merritt added 5 commits October 3, 2023 17:12

spelling errors

1c7f6af

made suggested formatting changes

d2d041c

changed Decin2023 back

4773a78

formatting to LSOL

90069d0

resolved issues around const marked perscriptions

fdf5ac9

Revert accidental commit "create a separate fiducial BBH COMPAS confi…

7073ea1

…g file (dont use the method paper config)" This reverts commit 346e98d.

set dominant mass loss flag in Belczynski2010 prescription

154fd4f

changed MASS_LOSS_TYPE names

007da8a

changed the default wolf-rayet-multiplier to 1.0

e82671c

Changed default wolf-rayet-multiplier to 1.0

463b31e

Jonathan Merritt added 2 commits November 1, 2023 11:23

Changed default wolf-rayet-multiplier to 1.0

acceb24

updated default yaml file with fWR=1.0

8d514dc

jeffriley and others added 2 commits November 2, 2023 07:57

Update whats-new.rst to reflect change to m_WolfRayetFactor default v…

eb3de1d

…alue

Update constants.h

2036978

Made LSOL and LSOLW consistent

ilyamandel approved these changes Nov 2, 2023

View reviewed changes

ilyamandel merged commit e39c6b7 into dev Nov 2, 2023
2 checks passed

ilyamandel deleted the updated_winds_fresh branch November 2, 2023 07:44

jeffriley pushed a commit to jeffriley/COMPAS-1 that referenced this pull request Dec 15, 2023

Merge pull request TeamCOMPAS#996 from TeamCOMPAS/updated_winds_fresh

d1a6078

Updated wind perscriptions

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Updated wind perscriptions #996

Updated wind perscriptions #996

jmerritt1 commented Sep 27, 2023 •

edited

Loading

SimonStevenson commented Sep 27, 2023 •

edited by jmerritt1

Loading

jmerritt1 commented Sep 27, 2023

jeffriley commented Sep 27, 2023

jeffriley commented Sep 27, 2023

jmerritt1 commented Sep 27, 2023

ilyamandel commented Sep 28, 2023

jmerritt1 commented Sep 28, 2023 •

edited

Loading

jeffriley commented Sep 29, 2023

jmerritt1 commented Sep 29, 2023

jeffriley left a comment •

edited

Loading

jeffriley commented Oct 3, 2023

jeffriley commented Oct 3, 2023

jeffriley commented Oct 3, 2023

SimonStevenson commented Oct 31, 2023 •

edited

Loading

jmerritt1 commented Oct 31, 2023 •

edited

Loading

ilyamandel commented Oct 31, 2023

ilyamandel commented Oct 31, 2023

SimonStevenson commented Oct 31, 2023 •

edited

Loading

ilyamandel commented Oct 31, 2023

SimonStevenson commented Oct 31, 2023

ilyamandel commented Oct 31, 2023

jmerritt1 commented Oct 31, 2023 •

edited

Loading

jmerritt1 commented Oct 31, 2023 •

edited

Loading

ilyamandel commented Nov 1, 2023 via email

jeffriley commented Nov 1, 2023

jmerritt1 commented Nov 1, 2023 •

edited

Loading

jeffriley commented Nov 1, 2023 •

edited

Loading

jmerritt1 commented Nov 1, 2023

ilyamandel left a comment

ilyamandel commented Nov 14, 2023

Updated wind perscriptions #996

Updated wind perscriptions #996

Conversation

jmerritt1 commented Sep 27, 2023 • edited Loading

SimonStevenson commented Sep 27, 2023 • edited by jmerritt1 Loading

jmerritt1 commented Sep 27, 2023

jeffriley commented Sep 27, 2023

jeffriley commented Sep 27, 2023

jmerritt1 commented Sep 27, 2023

ilyamandel commented Sep 28, 2023

jmerritt1 commented Sep 28, 2023 • edited Loading

jeffriley commented Sep 29, 2023

jmerritt1 commented Sep 29, 2023

jeffriley left a comment • edited Loading

Choose a reason for hiding this comment

jeffriley commented Oct 3, 2023

jeffriley commented Oct 3, 2023

jeffriley commented Oct 3, 2023

SimonStevenson commented Oct 31, 2023 • edited Loading

jmerritt1 commented Oct 31, 2023 • edited Loading

ilyamandel commented Oct 31, 2023

ilyamandel commented Oct 31, 2023

SimonStevenson commented Oct 31, 2023 • edited Loading

ilyamandel commented Oct 31, 2023

SimonStevenson commented Oct 31, 2023

ilyamandel commented Oct 31, 2023

jmerritt1 commented Oct 31, 2023 • edited Loading

jmerritt1 commented Oct 31, 2023 • edited Loading

ilyamandel commented Nov 1, 2023 via email

jeffriley commented Nov 1, 2023

jmerritt1 commented Nov 1, 2023 • edited Loading

jeffriley commented Nov 1, 2023 • edited Loading

jmerritt1 commented Nov 1, 2023

ilyamandel left a comment

Choose a reason for hiding this comment

ilyamandel commented Nov 14, 2023

jmerritt1 commented Sep 27, 2023 •

edited

Loading

SimonStevenson commented Sep 27, 2023 •

edited by jmerritt1

Loading

jmerritt1 commented Sep 28, 2023 •

edited

Loading

jeffriley left a comment •

edited

Loading

SimonStevenson commented Oct 31, 2023 •

edited

Loading

jmerritt1 commented Oct 31, 2023 •

edited

Loading

SimonStevenson commented Oct 31, 2023 •

edited

Loading

jmerritt1 commented Oct 31, 2023 •

edited

Loading

jmerritt1 commented Oct 31, 2023 •

edited

Loading

jmerritt1 commented Nov 1, 2023 •

edited

Loading

jeffriley commented Nov 1, 2023 •

edited

Loading