-
Notifications
You must be signed in to change notification settings - Fork 3
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
Allow TUV-x radiator data to be updated through the API #182
Conversation
std::size_t num_vertical_layers = 3; | ||
std::size_t num_wavelength_bins = 2; | ||
// Allocate array as 1D | ||
double* optical_depths_1D = new double[num_wavelength_bins * num_vertical_layers]; | ||
// Allocate an array of pointers to each row | ||
double** optical_depths = new double*[num_vertical_layers]; | ||
// Fill in the pointers to the rows | ||
for (int row = 0; row < num_vertical_layers; row++) | ||
{ | ||
optical_depths[row] = &optical_depths_1D[row * num_wavelength_bins]; | ||
} | ||
int i = 1; | ||
for (int row = 0; row < num_vertical_layers; row++) | ||
{ | ||
for (int col = 0; col < num_wavelength_bins; col++) | ||
{ | ||
optical_depths[row][col] = 10 * i; | ||
i++; | ||
} | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we like this? I initially wanted to use vector
but couldn't find a way to make it work for the fortran APIs to be able to index the array components. (e,g., optical_depths[col][row]
) @mattldawson, @K20shores, any thoughts on this implementation?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like this solution! This seems like it will work well with the fortran wrapper, and it keeps the data contiguous in memory
GetRadiatorOpticalDepths(radiator, optical_depths[0], num_vertical_layers, num_wavelength_bins, &error); | ||
ASSERT_TRUE(IsSuccess(error)); | ||
ASSERT_EQ(optical_depths[0][0], 10.0); | ||
ASSERT_EQ(optical_depths[0][1], 20.0); | ||
ASSERT_EQ(optical_depths[1][0], 30.0); | ||
ASSERT_EQ(optical_depths[1][1], 40.0); | ||
ASSERT_EQ(optical_depths[2][0], 50.0); | ||
ASSERT_EQ(optical_depths[2][1], 60.0); | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not confident whether this is the correct approach. Since the indices are transposed between Fortran and C, this setup of memory allocation is in favor of fortran, so in fortran side we can do indexing as following. @mattldawson, @K20shores, could you review this?
optical_depths(:,1) = (/ 30.0, 20.0, 10.0 /)
optical_depths(:,2) = (/ 70.0, 80.0, 90.0 /)
call radiator%get_optical_depths( temp_od, error )
ASSERT_EQ( temp_od(1,1), 30.0 )
ASSERT_EQ( temp_od(2,1), 20.0 )
ASSERT_EQ( temp_od(3,1), 10.0 )
ASSERT_EQ( temp_od(1,2), 70.0 )
ASSERT_EQ( temp_od(2,2), 80.0 )
ASSERT_EQ( temp_od(3,2), 90.0 )
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes, I think this is the best solution. The indexing is different, but the memory should be laid out in the optimal configuration regardless of how elements are accessed, and looping in C and Fortran should just be set up to access the elements in the optimal order:
for(int i=0; i < n_i; ++i)
for(int j=0; j < n_j; ++j)
optical_depths[i][j] = ...
and:
do i = 1, n_i
do j = 1, n_j
optical_depths(j,i) = ...
end do
end do
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That makes sense, thank you
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
looks great! Just a couple very minor suggestions. I agree with your suggestion of switching the struct
to class
docker/Dockerfile
Outdated
@@ -9,7 +9,7 @@ RUN dnf -y update \ | |||
gfortran \ | |||
gdb \ | |||
git \ | |||
lapack-devel \ | |||
# lapack-devel \ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we can probably just delete this line
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done!
docker/Dockerfile.fortran-gcc
Outdated
@@ -13,7 +13,7 @@ RUN dnf -y update \ | |||
git \ | |||
hdf5-devel \ | |||
json-devel \ | |||
lapack-devel \ | |||
# lapack-devel \ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can just delete this
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done!
@@ -14,7 +14,7 @@ RUN dnf -y update \ | |||
git \ | |||
hdf5-devel \ | |||
json-devel \ | |||
lapack-devel \ | |||
# lapack-devel \ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can delete
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done!
docker/Dockerfile.memcheck
Outdated
@@ -9,7 +9,7 @@ RUN dnf -y update \ | |||
gfortran \ | |||
gdb \ | |||
git \ | |||
lapack-devel \ | |||
# lapack-devel \ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can delete
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done!
docker/Dockerfile.mpi
Outdated
@@ -16,7 +16,7 @@ RUN sudo dnf -y install \ | |||
gcc-c++ \ | |||
gfortran \ | |||
git \ | |||
lapack-devel \ | |||
# lapack-devel \ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can delete
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done!
docker/Dockerfile.mpi_openmp
Outdated
@@ -16,7 +16,7 @@ RUN sudo dnf -y install \ | |||
gcc-c++ \ | |||
gfortran \ | |||
git \ | |||
lapack-devel \ | |||
# lapack-devel \ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can delete
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done!
docker/Dockerfile.openmp
Outdated
@@ -16,7 +16,7 @@ RUN sudo dnf -y install \ | |||
gcc-c++ \ | |||
gfortran \ | |||
git \ | |||
lapack-devel \ | |||
# lapack-devel \ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can delete
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done!
docker/Dockerfile.python
Outdated
@@ -9,7 +9,7 @@ RUN dnf -y update \ | |||
gcc-fortran \ | |||
gdb \ | |||
git \ | |||
lapack-devel \ | |||
# lapack-devel \ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can delete
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done!
Closes #122
Discussion:
I ended up choosing
class
to createRadiator
andRadiatorMap
because it hasprivate
member data and the usage offriend
declaration.struct
is used to createGrid
,GridMap
,Profile
andProfileMap
(they also have private member data). Althoughstruct
andclass
in C++ has no difference except for default access (public/private),struct
objects are somewhat expected to be all public, so I might vote for replacingstruct
withclass
. What do you all think? I think having consistency is important. (all of them should be eitherstruct
orclass
)