Rewrite of radiance documentation #896

lkugler · 2025-06-11T14:28:15Z

Description:

I think the radiance documentation needed some rewriting.
Please feel free to suggest additional changes / what's missing.
I think it shouldn't be a duplicate of the RTTOV user guide, but give an overview over capabilities, list advice, and give references to further material.

Fixes issue

None

Types of changes

Bug fix (non-breaking change which fixes an issue)
New feature (non-breaking change which adds functionality)
Breaking change (fix or feature that would cause existing functionality to not work as expected)
Documentation update

Documentation changes needed?

My change requires a change to the documentation.
- I have updated the documentation accordingly.

Tests

You can view the docs at readthedocs:
Radiance_support
obs-def-rttov-mod

Checklist for merging

Updated changelog entry
Documentation updated
Update conf.py

Checklist for release

Merge into main
Create release from the main branch with appropriate tag
Delete feature-branch

Testing Datasets

Dataset needed for testing available upon request
Dataset download instructions included
No dataset needed

hkershaw-brown · 2025-06-13T16:58:24Z

Thanks for the pull request Lukas! Most of the group is on travel this week and most of next week (I think), so we might be a little slow responding to this.

Cheers,
Helen

braczka · 2025-06-20T19:50:42Z

We appreciate this contribution @lkugler. I will have more time to review in the upcoming weeks, but from skimming through it -- these docs are much improved.

braczka · 2025-06-25T22:42:44Z

guide/Radiance_support.rst

+At present, DART supports RTTOV v12.3 and v13.  
+In version 12.3, RTTOV-direct for visible/infrared/microwave without 
+scattering as well as RTTOV-scatt for microwave computations with full 
+scattering are supported. The interface to v13 is limited to RTTOV-direct.


Do we need a bit more perspective regarding the limitations of only using RTTOV-direct without full scattering? How much does that deprecate results?

Good that you mention it. It's wrong that RTTOV-direct has no scattering.
see 375bc53

@lkugler As written this states that RTTOVv13 includes the ability to simulate microwave radiance --however the DART interface does not support microwave radiance with v13 because its limited to interacting with RTTOV-direct (UV/VIS/IR) and does not use the RTTOV-scatt (microwave) routine. Is that correct ? Seems like an important point. But looking at the RTTOV obs_def_mod for v12 and v13 there doesn't seem to be any checks or error codes to prevent users from using microwave with RTTOVv13 --- although the DART code still allows for namelist options related to microwave radiance. Could you clarify?

I didn't test the microwave operator before in v13, so I didn't want to claim that it works, sorry.
Now I tested the microwave operator (channel 20 of instrument ATMS on satellite NOAA-21) and noticed that for microwave in v13, the input variables were not using the indices lvlidx which flip the arrays if user chooses to, i.e. when first_lvl_is_sfc=T. Moreover, in the hydro(nlevels, ncategories) array, the order of hydrometeor categories was not correct. Currently it is Rain, Snow, Graupel, Cloud Liquid and Cloud Ice, in that order (says the user guide and the table I used (hydrotable_noaa_atms.dat). However, it depends on the hydrotable and thus might change in the future.
see edd2691, 2886faf, cb09fae

@lkugler This commit edd2691 (level ordering) looks like an important fix that applies to all wavebands (NIR/VIS/MW), whereas the other commits (cloudfraction and hydrometeor ordering) apply specifically to MW only. Could you confirm?

Exactly, for models that use first_lvl_is_sfc=.false.. Are there any models that use this convention? I think ECMWF-IFS and related ones maybe.
I think commit cb09fae is more important because it applies for potential WRF/MPAS microwave users.

Something similar was fixed in 2022 (#365 ). Before that, arrays for VIS/IR were flipped twice. Once when the cloud variables are summed up into totalwater/totalice and once when they were assigned to the RTTOV input array runtime % profiles(imem) % cloud(:,:). Obviously arrays need to be flipped only once if first_lvl_is_sfc=T.

braczka · 2025-06-25T22:44:37Z

guide/Radiance_support.rst

+To compile DART with RTTOV, perform the following steps:
+
+
+**1. Install RTTOV**


These edits have removed a separate guide for compiling and installing DART-RTTOV 'Getting started with DART RTTOV' originally created by Tim Hoar. Not sure if there is anything worthwhile to retain in those instructions, or whether new steps are enough. Maybe Helen can add some perspective there.

I think the edits by Lukas are a great improvement. They give specific instructions for the DART part of the process direct the user to external (RTTOV) documentation when needed.
I am happy to to remove the link to https://github.com/NCAR/DART/wiki/Getting-Started-with-DART-RTTOV since this is out of date (quickbuild.csh).

EDIT: I will include Tim's instructions on the page, as I found them helpful now while I was doing a fresh install.
Moreover, I'd point to the quick start beginners guide in case our docs become outdated at some point.

Tim's instructions look good incorporated in the High-Level workflow section -- I will clean up the syntax a bit.

Addressed in f227bc1

braczka · 2025-06-25T22:49:37Z

guide/Radiance_support.rst

+   *  The Deff scheme (`clw_scheme=2`) computes optical properties from an effective particle diameter as input.
+      By default, DART accesses the model state variable associated with ``QTY_CLOUDWATER_DE`` in the DART namelist.


Technically the default obs_def_rttov_mod code currently in the DART repository prescribes a fixed effective diameter value -- and does not use the QTY_CLOUDWATER_DE value. Should the opposite be true?

In v13, the code defines a default size. In v12 it doesn't.
I added the default in v12 too now: 4d671f2

Moreover, I added the necessary code such that the particle size can be read from WRF: b0adf4c
However, it might be better NOT to have it as default (to read particle sizes from any model), as I only checked it for WRF and it's likely that you'll run into errors in other models. Also, depending on the configuration, the variable is not in WRF output.
If we don't want to read from file as default, then we only need to comment out the interpolate() command in obs_def_rttov_mod.f90

I agree that we make the prescribed/reasonable particle size as the default option, but If DART finds the QTY_CLOUDWATER_DE value within the DART state, it assumes the user wants to use the model liquid particle size as input and will perform the interpolate() and overwrite the default values. The ice particle size is determined by the 'use_icede' namelist option false = use prescribed/fixed value, true= use model value from QTY_CLOUD_ICE_DE. If using the modeled particle diameter (from WRF) I think we still need the meter to micron units conversion as well. I will have a go at this.

Addressed in 71e8ef1

braczka · 2025-06-25T22:51:00Z

guide/Radiance_support.rst

+A good overview over the most important parameters for the radiative transfer
+can be found in the RTTOV user guide section "Simulation of UV, visible and IR cloud-affected radiances".


I actually couldn't find this section in the RTTOV user guide --- did the sections change with the updated RTTOV version, or did I just miss it?

Ah, that's the v14 guide, which changed a lot. The guide for v12 and v13 is quite hidden now.
Is it ok to add links to the pages where v12/v13 are still available?
5bbbe46

braczka · 2025-06-25T22:52:20Z

guide/Radiance_support.rst

+      in cloud phase (ice versus water) makes a much larger difference. 

-https://github.com/NCAR/DART/wiki/Getting-Started-with-DART-RTTOV
+#. Ice clouds


Why call out Ice clouds specifically, if there is not specific information given in this doc? Can we provide similar scientific guidance for Ice clouds similar to liquid clouds above?

Yes, there was something missing. See 282ed10

something else

There in the docs, I mentioned another feature that would be great for anyone comparing with real observations:
One should only count 10% of "snow" towards ice. It sounds like a ad-hoc estimate, but it's a good estimate, supposedly.
It would be good if we could add that multiplier to snow (

DART/observations/forward_operators/obs_def_rttov13_mod.f90

Line 2195 in d908222

totalice(:) = totalice(:) + max(clouds % snow(imem,:),0.0_r8)

) and which is only 0.1 for visible radiances and 1.0 else.
If not implemented, then at least it's important to make new users aware of that.

It seems it would be straightforward to implement this by using the logical 'is_vis' option. If true apply the 0.1 multiplier, if false keep at 1.0.

Addressed in 9aa7dcf

braczka

@lkugler Your suggested changes were much needed. Could you take a look at my text changes, and make sure this is consistent with your understanding. Also -- could you take a look at my specific questions, where I am looking for more scientific feedback.

guide/Radiance_support.rst

… radiance-docs

lkugler · 2025-07-10T16:21:59Z

observations/forward_operators/obs_def_rttov13_mod.f90

-         ! TODO: specify cfrac (scalar?!)
-         ! runtime % cld_profiles(imem) % cfrac = ? not implemented
+         ! Custom cfrac = vertical maximum of the cloud fraction
+         runtime % cld_profiles(imem) % cfrac = max(min(maxval(clouds % cfrac(imem,lvlidx)), 1.0_r8), 0.0_r8)


Before, this was not specified. Now I set this microwave-related (scalar) cloudfraction to the vertical maximum cloud fraction in a column. I'm not sure if this is correct.

@lkugler I think using the the maximum cloud fraction of the vertical profile taken from WRF as a proxy for the effective cloud fraction (cfrac) required by RTTOV is a good estimate. The scalar 'effective cloud fraction' being the cloud fraction coverage across the ground. The way I see it is that the effective cloud fraction could be no greater than the maximum vertical profile cloud fraction. Depending on grid resolution the cloud fraction will be binary in most cases, I think -- either 0 or 1, so if cloud fraction is 1 at any point in profile, the effective cloud fraction is 1. Seems like this will work.

braczka · 2025-07-10T18:13:49Z

observations/forward_operators/obs_def_rttov13_mod.f90

+         runtime % cld_profiles(imem) % hydro_frac(:,:) = 1.0_jprb
+         ! runtime % cld_profiles(imem) % hydro_frac(:,:) = clouds % cfrac(imem,lvlidx)


@lkugler This seems incorrect. If the cfrac is defined then hydro_frac is assumed to equal cfrac. Can you confirm?

By the user guide, hydro_frac(nlevels, nhydro_frac) describes cloud fraction (0-1) on nlevels for nhydro_frac many hydrometeor categories.
If we assume nhydro_frac=1, then we can set hydro_frac(:,1) = cfrac(:) since we don't have any other information on the spatial extent of rain/snow/graupel/hail within a grid box.

So I think that we can have
runtime % cld_profiles(imem) % hydro_frac(:,1) = clouds % cfrac(imem,lvlidx), right?

@lkugler Yes -- I think this is correct and we can switch the line that is commented out such that we specify vertical cloud fraction across all hydrometeors as : <runtime % cld_profiles(imem) % hydro_frac(:,1) = clouds % cfrac(imem,lvlidx).

The nhydro_frac is already defined as 1 during the rttov_alloc_scatt_prof call within obs_def_rttov13, so the dimensions should work. I don't see how we could pry any more information out of WRF to specify a per hydrometeor cloud fraction? On a subgrid scale WRF isn't capable of providing this information I wouldn't think.

Yes. We can assume that as long as we put a note into the documentation.

braczka · 2025-07-18T23:03:25Z

observations/forward_operators/obs_def_rttov13_mod.f90


-      ! code proposed, depends on the hydrotables of RTTOV?
-      ! TODO: adapt to hydrotable, change indices of hydro(:,X) <--- here
+      ! This code may depend on hydrotables of RTTOV


@lkugler For RTTOV13, however, it looks like the hydrotable order is fixed as you have defined from RTTOV13 users guide:

"Number of hydrometeor types considered by RTTOV-SCATT. The correct number of hydrometeors, and the order in which they are specified, is controlled by the hydrotable*.dat coefficient files. Using standard hydrotables obtained from the NWP SAF website, RTTOVSCATT will expect 5 hydrometeors (rain, snow, graupel, cloud water, cloud ice, in that order), but hydrotables can contain properties for any number of hydrometeor types. "

Note to self -- Looks like with latest commits WRF-DART RTTOV13 now compatible with microwave emission. Test this and then update docs to reflect this update.

Would you like my model data or namelists to create a test case?

@lkugler What I have been doing thus far is performing a WRF-DART PMO with microwave observations (EOS_AMSU-A) to test out this functionality. Derecho is down the next few days, but it would be nice to have a test case for microwave obs, especially with a wrf simulation where you output cloud fraction (CFRAC). Currently I don't have a wrf run that outputs CFRAC, which would be necessary to test some of the new functionality we have added.

I have completed my testing for the microwave RTTOV13 functionality. I used EOS_2_AMSUA_TB observations and picked locations of cloudy and clear conditions and this seemed to give reasonable BT values. My tests can be found here: /glade/work/bmraczka/DART/models/wrf/MW_rttov13_fix. I used perfect_model_obs to generate synthetic obs from a wrfinput file based on the CONUS region, with the objective to exercise the new RTTOV13 microwave functionality with a variety of options. I performed two alternative test cases which used empirical formulations for effective hydrometeor radius and cloud fraction, and also prescribed hydrometeor radius and cloud fraction provided from WRF. Roughly speaking these were the namelist settings for each case:

empirical DE &obs_def_rttov settings:

cfrac_data = .false. clw_data = .true. rain_data = .true. ciw_data = .false. snow_data = .false. graupel_data = .false. hail_data = .false. .. .. clw_scheme = 1 use_icede = .false.

prescribed DE &obs_def_rttov settings:

cfrac_data = .true. clw_data = .true. rain_data = .true. ciw_data = .true. snow_data = .true. graupel_data = .true. hail_data = .false. .. .. clw_scheme = 2 use_icede = .true.

@lkugler If you had a test case you wanted to run through, please go ahead, otherwise I think this is ready to go.

@braczka Perfect. Thank you!

is_vis logical needed to be defined

Also provide more info on prescribing hydrometeor effective radius for microwave calculation

hkershaw-brown · 2025-08-25T13:18:46Z

Hi all, just checking in on this radiance documentation pull request #896. Is this ready to me merged and released?
Cheers,
Helen

lkugler · 2025-08-25T13:42:47Z

It's ready to be released, right @braczka ?

hkershaw-brown · 2025-08-26T19:16:39Z

observations/forward_operators/obs_def_rttov_mod.f90

         if (allocated(clouds % snow)) then
-            totalice(:) = totalice(:) + max(clouds % snow(imem,lvlidx),0.0_r8)
+            ! Following Kostka et al., 2014
+            if (is_vis) then


is_vis is not defined in obs_def_rttov_mod.f90 so this module does not compile:

/glade/derecho/scratch/hkershaw/DART/pull_reqeuests/pull_896/DART/observations/forward_operators/obs_def_mod.f90(1914): error #6404: This name does not have a type, and must have an explicit type. [IS_VIS]
if (is_vis) then

Does this need is_vis defined the same way as rttov13:
is_vis = sensor%sensor_type_name == 'vis'

I think I only applied this commit to obs_def_rttov_mod13.f90 in order to create is_vis, but probably should be applied to obs_def_rttov_mod.f90 as well ??

This commit: 817cf37

It does look like the is_vis line was just missed from obs_def_mod_rttov.f90. @braczka Do you want me to go ahead and make the change to add in is_vis = sensor%sensor_type_name == 'vis'?

I cannot recreate the build error -- I can successfully build on derecho for this pull request using template mkmf.template.rttov.gfortran for RTTOV 13 using:
RTTOV = /glade/campaign/cisl/dares/libraries/rttov132_gfortran/
RTTOV_VERSION = 13

with the preprocess_nml pointing to:
obs_type_files = '../../../observations/forward_operators/obs_def_rttov13_mod.f90',

and I can successfully build RTTOV 12 using:
RTTOV = /glade/campaign/cisl/dares/libraries/rttov123_gfortran/
RTTOV_VERSION = 12

with the preprocess_nml pointing to:
obs_type_files = '../../../observations/forward_operators/obs_def_rttov_mod.f90',

@braczka which branch are you building, Lukas's branch (this pull request) or NCAR/radiance-docs where I fixed the compile issue?
main...radiance-docs

I guess it was the NCAR/radiance-docs because now that I look at the obs_def_rttov_mod.f90 it has the is_vis changes -- didn't realize those changes had been implemented given your last comment.

Regardless - this seems to be resolved and so just go ahead as you see fit.

The changes haven't been implemented on this pull request. Its two different branches.

Can you give a summary of the code changes for the release notes, the description in the pull request only has the documentation rewrite.

Thanks,
Helen

I don't have access to a computer so just popping notes in here:

Enables microwave radiance emission for RTTOV13

Allows user to bring in liquid/ice effective droplet radius from model
as alternative to the fixed default value

Specifies the max cloudfraction from the model as the
effective cloud fraction

Fixes hydrometeor type 'hydrotable' to expect the order: rain, snow, graupel, cloud water
cloud ice.

For visible radiance applies empirical 0.1 factor against snow when calculating
total cloud ice

Contributed with help from Lukas Kugler

hkershaw-brown

leaving this on request changes, obs_def_rttov_mod.f90 does not not compile

models/wrf/model_mod.f90

observations/forward_operators/obs_def_rttov13_mod.f90

hkershaw-brown · 2025-08-29T19:52:28Z

guide/Radiance_support.rst

+   export RTTOV=${RTTOV_install}
+   cd $DART/models/wrf/work/
+   ln -sf $DART/observations/forward_operators/rttov_sensor_db.csv .
+   ln -sf $RTTOV/rtcoef_rttov13/cldaer_visir/sccldcoef_msg_4_seviri.dat  .


rtcoef_rttov13, however the build instructions are for rttov12 (obs_def_rttov_mod.f90)

observations/forward_operators/obs_def_rttov_mod.f90

hkershaw-brown · 2025-08-29T20:03:10Z

observations/forward_operators/obs_def_rttov_mod.rst

-DART can be built with either RTTOV v12 *or* v13. Edit :ref:`&preprocess_nml <preprocess>` to select
-the appropriate obs_def:
-
- obs_def_rttov_mod.f90 for v12.3
- obs_def_rttov13_mod.f90 for v13 (contributed by Lukas Kugler of the University of Vienna).  
-
-Note the namelist options for &obs_def_rttov_nml differ for v12 and v13.
-
- `RTTOV v12 Namelist`_ &obs_def_rttov_nml
- `RTTOV v13 Namelist`_ &obs_def_rttov_nml


How to compile with rttov v12 or v13 seems to be missing from the new documentation, unless I'm missing something. This seems pretty important info for compiling DART with RTTOV.

Co-authored-by: Helen Kershaw <[email protected]>

braczka

Accepted all precision changes, and suggesting to add back instructions on RTTOV v12 versus v13 compile.

braczka · 2025-09-08T15:16:59Z

observations/forward_operators/obs_def_rttov_mod.rst

-
+radiances/brightness temperatures. Observations from a wide range of satellites (e.g. GOES, FY, METOP, ...) and 
+sensors (e.g. ABI, AMSU-A, SEVIRI, ...) are supported 
+(`see the complete list here <https://nwp-saf.eumetsat.int/site/software/rttov/documentation/platforms-supported/>`__).


Suggested change

(`see the complete list here <https://nwp-saf.eumetsat.int/site/software/rttov/documentation/platforms-supported/>`__).

(`see the complete list here <https://nwp-saf.eumetsat.int/site/software/rttov/documentation/platforms-supported/>`__).

DART can be built with either RTTOV v12 *or* v13. Edit :ref:`&preprocess_nml <preprocess>` to select

the appropriate obs_def:

- obs_def_rttov_mod.f90 for v12.3

- obs_def_rttov13_mod.f90 for v13

Note the namelist options for &obs_def_rttov_nml differ for v12 and v13.

- `RTTOV v12 Namelist`_ &obs_def_rttov_nml

- `RTTOV v13 Namelist`_ &obs_def_rttov_nml

@hkershaw-brown I agree that we want to still include instructions for v12.3 and v13. I suggest adding back these instructions here to toggle between obs_def_rttov_mod.f90 and obs_def_rttov13_mod.f90 in preprocess namelist.

hkershaw-brown

Thanks @lkugler & @braczka!

lkugler and others added 8 commits May 22, 2025 16:05

first textual overhaul

601ce5e

rewrite radiance docs

22d0eb2

rewrite

c408464

rewrite

b42cfe1

rewrite

5034e69

rewrite

9514598

link not working

0b67661

Merge branch 'main' into radiance-docs

c676370

braczka self-requested a review June 23, 2025 23:23

braczka added 2 commits June 24, 2025 17:50

Edited RTTOV radiance_support docs

b1f2238

Modify obs_def_rttov docs

9adbf26

braczka reviewed Jun 25, 2025

View reviewed changes

braczka requested changes Jun 25, 2025

View reviewed changes

hkershaw-brown reviewed Jun 30, 2025

View reviewed changes

guide/Radiance_support.rst Outdated Show resolved Hide resolved

hkershaw-brown reviewed Jun 30, 2025

View reviewed changes

guide/Radiance_support.rst Outdated Show resolved Hide resolved

hkershaw-brown reviewed Jun 30, 2025

View reviewed changes

guide/Radiance_support.rst Show resolved Hide resolved

lkugler added 3 commits July 1, 2025 17:57

Merge remote-tracking branch 'refs/remotes/origin/radiance-docs' into…

0e359a2

… radiance-docs

remark about direct/scatt

375bc53

install RTTOV paragraph

abf0c38

lkugler force-pushed the radiance-docs branch from 8edbf5b to abf0c38 Compare July 3, 2025 16:03

lkugler added 4 commits July 4, 2025 17:48

particle diameters from WRF

b0adf4c

default diameter in v12

4d671f2

link to v12/v13 guides

5bbbe46

added info about ice clouds

282ed10

lkugler commented Jul 10, 2025

View reviewed changes

braczka reviewed Jul 10, 2025

View reviewed changes

braczka reviewed Jul 18, 2025

View reviewed changes

braczka added 5 commits July 25, 2025 10:29

If visible range adjust snow crossection

817cf37

is_vis logical needed to be defined

Assign cloud_frac per each hydrometeor type

b7a4b43

Incorrect WRF types for effective hydro radius

440bdb6

Removing radius to diam hydrometeor conversion

b938723

Update docs for microwave RTTOV13 support

ee9a30f

Also provide more info on prescribing hydrometeor effective radius for microwave calculation

braczka approved these changes Aug 25, 2025

View reviewed changes

hkershaw-brown added the release! bundle with next release label Aug 25, 2025

Merge branch 'main' into radiance-docs

f9546cb

hkershaw-brown reviewed Aug 26, 2025

View reviewed changes

hkershaw-brown requested changes Aug 26, 2025

View reviewed changes

hkershaw-brown added release+1 bundle with release after next and removed release! bundle with next release labels Aug 27, 2025

hkershaw-brown reviewed Aug 29, 2025

View reviewed changes

models/wrf/model_mod.f90 Outdated Show resolved Hide resolved

hkershaw-brown reviewed Aug 29, 2025

View reviewed changes

observations/forward_operators/obs_def_rttov13_mod.f90 Outdated Show resolved Hide resolved

hkershaw-brown reviewed Aug 29, 2025

View reviewed changes

observations/forward_operators/obs_def_rttov_mod.f90 Outdated Show resolved Hide resolved

hkershaw-brown reviewed Aug 29, 2025

View reviewed changes

hkershaw-brown removed the release+1 bundle with release after next label Sep 2, 2025

Adding double precision to numerical constants

66e6faa

Co-authored-by: Helen Kershaw <[email protected]>

braczka reviewed Sep 8, 2025

View reviewed changes

hkershaw-brown and others added 2 commits September 17, 2025 09:08

Merge branch 'main' into radiance-docs

db1e772

fix: add is_vis logical

b6ee167

hkershaw-brown approved these changes Sep 17, 2025

View reviewed changes

hkershaw-brown added the release! bundle with next release label Sep 17, 2025

hkershaw-brown merged commit 7b50df6 into NCAR:main Sep 17, 2025
99 checks passed

		To compile DART with RTTOV, perform the following steps:


		1. Install RTTOV

		* The Deff scheme (`clw_scheme=2`) computes optical properties from an effective particle diameter as input.
		By default, DART accesses the model state variable associated with ``QTY_CLOUDWATER_DE`` in the DART namelist.

		A good overview over the most important parameters for the radiative transfer
		can be found in the RTTOV user guide section "Simulation of UV, visible and IR cloud-affected radiances".

		runtime % cld_profiles(imem) % hydro_frac(:,:) = 1.0_jprb
		! runtime % cld_profiles(imem) % hydro_frac(:,:) = clouds % cfrac(imem,lvlidx)

Rewrite of radiance documentation #896

Rewrite of radiance documentation #896

Uh oh!

Conversation

lkugler commented Jun 11, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description:

Fixes issue

Types of changes

Documentation changes needed?

Tests

Checklist for merging

Checklist for release

Testing Datasets

Uh oh!

hkershaw-brown commented Jun 13, 2025

Uh oh!

braczka commented Jun 20, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

lkugler Jul 3, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

lkugler Jul 10, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

lkugler Jul 3, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

lkugler Jul 4, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

lkugler Jul 4, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

lkugler Jul 4, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

something else

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

braczka left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

lkugler commented Jun 11, 2025 •

edited

Loading

lkugler Jul 3, 2025 •

edited

Loading

lkugler Jul 10, 2025 •

edited

Loading

lkugler Jul 3, 2025 •

edited

Loading

lkugler Jul 4, 2025 •

edited

Loading

lkugler Jul 4, 2025 •

edited

Loading

lkugler Jul 4, 2025 •

edited

Loading

lkugler Jul 10, 2025 •

edited

Loading