Opened 8 years ago

Closed 12 months ago

Problem in snow albedo computation

Reported by: Owned by: maignan peylin major ORCHIDEE 4.2 Physical processes trunc

Description

Dan Zhu and Pascale Braconnot have reported an inconsistency in the snow albedo computation, depending on whether you're using DGVM or not.
In condveg_snow, we find:

```         ! For  vegetated surfaces
fraction_veg(:) = un - totfrac_nobio(:)
snowa_veg(:) = zero
IF (ok_dgvm) THEN
DO ji = 1, kjpindex
IF ( fraction_veg(ji) .GT. min_sechiba ) THEN
snowa_veg(ji) = snowa_veg(ji) + &
tot_bare_soil(ji)/fraction_veg(ji) * ( snowa_aged(1)+snowa_dec(1)*agefunc_veg(ji) )
END IF
END DO

DO jv = 2, nvm
DO ji = 1, kjpindex
IF ( fraction_veg(ji) .GT. min_sechiba ) THEN
snowa_veg(ji) = snowa_veg(ji) + &
veget(ji,jv)/fraction_veg(ji) * ( snowa_aged(jv)+snowa_dec(jv)*agefunc_veg(ji) )
ENDIF
ENDDO
ENDDO
ELSE
DO jv = 1, nvm
DO ji = 1, kjpindex
IF ( fraction_veg(ji) .GT. min_sechiba ) THEN
snowa_veg(ji) = snowa_veg(ji) + &
veget_max(ji,jv)/fraction_veg(ji) * ( snowa_aged(jv)+snowa_dec(jv)*agefunc_veg(ji) )
ENDIF
ENDDO
ENDDO
ENDIF
```

Catherine Ottlé says the right formulation is the one using tot_bare_soil and veget, meaning the ok_dgvm case.
The code should then be replaced with:

```         ! For  vegetated surfaces
fraction_veg(:) = un - totfrac_nobio(:)
snowa_veg(:) = zero
DO ji = 1, kjpindex
IF ( fraction_veg(ji) .GT. min_sechiba ) THEN
snowa_veg(ji) = snowa_veg(ji) + &
tot_bare_soil(ji)/fraction_veg(ji) * ( snowa_aged(1)+snowa_dec(1)*agefunc_veg(ji) )
END IF
END DO

DO jv = 2, nvm
DO ji = 1, kjpindex
IF ( fraction_veg(ji) .GT. min_sechiba ) THEN
snowa_veg(ji) = snowa_veg(ji) + &
veget(ji,jv)/fraction_veg(ji) * ( snowa_aged(jv)+snowa_dec(jv)*agefunc_veg(ji) )
ENDIF
ENDDO
ENDDO
```

comment:1 Changed 6 years ago by jgipsl

• Owner changed from somebody to peylin
• Status changed from new to assigned

comment:2 Changed 6 years ago by jgipsl

• Milestone changed from IPSLCM6.v1 to ORCHIDEE 3.0
• Type changed from defect to enhancement

Due to decision on Tuesday meeeting : The method for the case ok_dgvm=false is now used in both cases, see commit [4691].

The ticket stays open because as Catherine says above, the other method might be better but needs more tests.

comment:3 Changed 4 years ago by jgipsl

Said during ORCH meeting today:

PP has discussed with CO, they will prepare a version with the modifications. PP will then ask AD for check before commit. PP will meet with Josefine to commit.

comment:4 Changed 4 years ago by peylin

Philippe P: we have proposed together with Catherine to use two different approaches for high vegetation covers (Trees) versus low vegetation cover (Grass, crop).
For high vegetation cover, we should keep the formulation with vegetmax as the bare soil part when there is no/few leaves (difference between veget and vegetmax) we should still consider that the "aging function" for the albedo of Tree with branches/trunk is similar to the one when there is leaves.
On the other hand, for short grass/crop vegetation, the bare soil part when there is not/few leaves should be treated as the standard bare soil fraction (veget(1)).
The code has been modified by PP for Josefine to commit.
Philippe

comment:5 Changed 4 years ago by jgipsl

Done in the trunk [6523]

comment:6 Changed 4 years ago by peylin

The Routine CONDVEG_ALBEDO has been modified to account for the proposed modifications.

! The new rational for the snow albedo and its dependency to snow age is (see ticket 223; PP Fevrier 2020) :
! i) Short vegetation (grass, crop): we assume that when there is no leaves (LAI=0), the snow aging is not
! impacted by the vegetation. The difference between veget and vegetmax (bare soil fraction within the PFT
! should be considered in the same way as the bare soil fraction (PFT1).
! ii) High vegetation (Tree): In this case we consider that the vegetation impacts the snow aging even when
! LAI=0 because of the trunks, branches. So these PFTs should be treated differently without any
! consideration of the bare soil fraction within the PFT.

comment:7 Changed 4 years ago by peylin

• Resolution set to fixed
• Status changed from assigned to closed

comment:8 Changed 3 years ago by nvuilsce

A bug was introduced in the last commit [6523] for the treatment of bare soil (PFT1). For PFT1, veget equals veget_max and not zero. It resulted in an albedo of zero for Greenland.
A correction has been proposed by P. Peylin and commited in branch ORCHIDEE_3 [6907]

comment:9 Changed 3 years ago by peylin

• Resolution fixed deleted
• Status changed from closed to reopened

Following the correction on the snow albedo (for bare soil PFT), several actions are needed:

• Test the comit in branch ORCHIDEE_3 in the current Trunk
• Evaluate if the "non intuitive" fact that veget equals veget_max for PFT1 and not zero may cause some problem elsewhere in the code ?

Make these test before closing the ticket

comment:10 Changed 3 years ago by maignan

The same concerns was already expressed in #404.

comment:11 Changed 16 months ago by nvuilsce

• Milestone changed from ORCHIDEE 3.0 to ORCHIDEE 4.2

comment:12 Changed 12 months ago by xnwang

In trunk:
tot_bare_soil_notree(: ) = 0
DO ipts = 1, kjpindex

DO ivm=1,nvm

IF ( fraction_veg(ipts) .GT. min_sechiba .AND. .NOT. is_tree(ivm) ) THEN

tot_bare_soil_notree(ipts) = tot_bare_soil_notree(ipts) + veget_maipts,ivm) - veget(ipts,ivm)

In orchidee tag 3:
tot_bare_soil_notree( : ) = veget_max(:,1)
The iterration over pfts starts from 2, not from 1.

Without the modification, we compute tot_bare_soil_notree by summing over ivm from 1 to nvm, so the veget_max from baresoil is taken into account.

With the modification (to be the same as Tag3), the tot_bare_soil_notree is initialized with veg_max at bare soil. Then we compute tot_bare_notree by summing over imv from 2 to nvm. So finally tot_bare_soil_notree is computed in the same way, with or without the modification.

Some test simulations were done by applying the modifications to the trunk. Then comparisons were made on albedo results with and without modification. There is no difference in the albedo results, which confirms the above analysis of code.

comment:13 Changed 12 months ago by xnwang

• Resolution set to fixed
• Status changed from reopened to closed

The question mentioned in this ticket is clarified. The ticket can be closed. Some new issues were found while studying this ticket, which would be put into a new ticket.

Note: See TracTickets for help on using tickets.