Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add diag_manager testing for openmp #1281

Merged
merged 27 commits into from
Jul 31, 2023

Conversation

uramirez8707
Copy link
Contributor

@uramirez8707 uramirez8707 commented Jul 11, 2023

Description

  • Adds testing for openmp
  • Updates code to prevent a race condition when allocating the data buffer and setting the flags

Fixes # (issue)

How Has This Been Tested?
CI

Checklist:

  • My code follows the style guidelines of this project
  • I have performed a self-review of my own code
  • I have commented my code, particularly in hard-to-understand areas
  • I have made corresponding changes to the documentation
  • My changes generate no new warnings
  • Any dependent changes have been merged and published in downstream modules
  • New check tests, if applicable, are included
  • make distcheck passes

uramirez8707 and others added 12 commits April 6, 2023 14:23
* fix - gnu and pgi issue with class(*) in send_data3d (NOAA-GFDL#1149)

* feat: extend `string` interface in `fms_string_utils_mod` (NOAA-GFDL#1142)

* fix: add omp directives for race condition in tridiagonal (NOAA-GFDL#1109)

* fix: missing if statement in PR NOAA-GFDL#1149 (NOAA-GFDL#1155)

* fix: time_manager missing changes from year to yr, month to mo, day to dy (NOAA-GFDL#1169)

* chore: update changelog and version numbers for release (NOAA-GFDL#1167)

* chore: append dev to version number post-release (NOAA-GFDL#1179)

---------

Co-authored-by: Niki Zadeh <[email protected]>
Co-authored-by: Jesse Lentz <[email protected]>
Co-authored-by: ganganoaa <[email protected]>
Co-authored-by: MiKyung Lee <[email protected]>
Co-authored-by: Ryan Mulhall <[email protected]>
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
@uramirez8707 uramirez8707 marked this pull request as draft July 20, 2023 15:40
… old diag manager, fix possible race condition
@uramirez8707 uramirez8707 marked this pull request as ready for review July 20, 2023 19:03
Copy link
Contributor

@ganganoaa ganganoaa left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some changes may be required but not critical to code function.

@@ -484,7 +477,6 @@ logical function allocate_data_buffer(this, input_data, diag_axis)
call mpp_error ("allocate_data_buffer","The data input to set_data_buffer for "//&
trim(this%varname)//" is not a supported type", FATAL)
end select
!$omp end single
allocate_data_buffer = allocated(this%data_buffer)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it good to add the following statement here?
this%set_data_buffer_is_allocated(allocated(this%data_buffer))

class (fmsDiagField_type) , intent(inout) :: this !< The field object
logical, intent (in) :: data_buffer_is_allocated !< Flag saying that the math
!! functions need to be done

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Comment for data_buffer_is_allocated is misleading.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@uramirez8707 you can tell us the .true. means the data buffer is allocated. it seems obvious but not all of the variables are always obvious

call this%FMS_diag_fields(diag_field_id)%set_data_buffer(field_data, FMS_diag_object%diag_axis,&
is, js, ks, ie, je, ke)

!> Only 1 thread allocates the output buffer amd sets set_math_needs_to_be_done
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

typo amd

!> Only 1 thread allocates the output buffer amd sets set_math_needs_to_be_done
!$omp single
data_buffer_is_allocated = &
this%FMS_diag_fields(diag_field_id)%allocate_data_buffer(field_data, FMS_diag_object%diag_axis)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We need to avoid use of global variables/objects as much as we can. There could be multiple global instances of fmsDiagObject_type. Here, diag_axis is associated to an instance this but not to any other instance. Every time we change the global instance of the fmsDiagObject_type we have to come back here and change accordingly which is not good. So, FMS_diag_object%diag_axis should be replaced by this%diag_axis.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes! Good catch! Thanks.

this%data_buffer_allocated = allocate_data_buffer(this, input_data, diag_axis)
if (.not.this%data_buffer_allocated) &
integer :: is, js, ks !< Starting indicies of the field_data relative to the global domain
integer :: ie, je, ke !< Ending indicied of the field_data relative to the global domain
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

typo indicied

class (fmsDiagField_type) , intent(inout):: this !< The field object
class(*), dimension(:,:,:,:), intent(in) :: input_data !< The input array
class(fmsDiagAxisContainer_type),intent(in) :: diag_axis(:) !< Array of diag_axis
integer :: is, js, ks !< Starting indicies of the field_data
integer :: ie, je, ke !< Ending indicied of the field_data
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

typo indicied

class (fmsDiagField_type) , intent(inout) :: this !< The field object
logical, intent (in) :: data_buffer_is_allocated !< Flag saying that the math
!! functions need to be done

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@uramirez8707 you can tell us the .true. means the data buffer is allocated. it seems obvious but not all of the variables are always obvious

is, js, ks, ie, je, ke)

!> Only 1 thread allocates the output buffer and sets set_math_needs_to_be_done
!$omp critical
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

urg but agreed

axis_loop: do a = 1,naxes
axis_id => this%axis_ids(a)
select type (axis => diag_axis(axis_id)%axis)
type is (fmsDiagFullAxis_type)
length(a) = axis%axis_length()
end select
enddo axis_loop
!> On a single thread, allocate the data buffer to the correct kind and size
!$omp single

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This doesnt need to be in a single/critical section?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This function is called in a critical section, so there is no need for it here.

@thomas-robinson thomas-robinson merged commit 7c763af into NOAA-GFDL:dmUpdate Jul 31, 2023
27 checks passed
rem1776 pushed a commit to rem1776/FMS that referenced this pull request May 1, 2024
rem1776 pushed a commit to rem1776/FMS that referenced this pull request May 1, 2024
rem1776 pushed a commit to rem1776/FMS that referenced this pull request May 1, 2024
rem1776 pushed a commit to rem1776/FMS that referenced this pull request May 1, 2024
rem1776 pushed a commit to rem1776/FMS that referenced this pull request May 1, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants