Dkokron/reduce startup time

What changes does this PR introduce?
Improved interaction with Pleiades Lustre file systems.  This PR addresses several issues in the current code resulting in a 200 second savings during startup (~300s -> ~90s) for the llc_540 case.

Each MPI process creates and reads numerous scratch files in the case directory.  I moved these to /tmp saving O(10^4) MDS hits

Each MPI process reads numerous small configuration files from the case directory.  I moved these to /tmp saving O(10^4) MDS hits.  Requires that the user pre-populate /tmp on each node.  I accomplish this on pleiades using
pdsh -w /u/scicon/tools/bin/pbs_nodes $PBS_JOBID "cd $PWD; mkdir -p /tmp/namelist; /bin/cp data eedata data.{bbl,cal,diagnostics,exch2,exf,kpp,pkg,salt_plume,seaice} /tmp/namelist/"

The code uses the Fortran default action when opening files for read-only access.  Fortran defaults to action=' READWRITE ' when opening files.  If a user does not have write access (think shared boundary conditions), then the first attempt to access the file will fail.  The fortran runtime then attempts to open the file action='read' which then succeeds.  While this can be very fast, it depends greatly on how busy the Lustre meta-data server (MDS) is.  Considering the MDS is a shared resource, all these extra MDS hits really just contribute extra load on an already burdened resource.  I added action='read' to all of the open() statements where IOT indicated it would be useful.

Changed files
modified:   eesupp/src/eeset_parms.F
modified:   eesupp/src/open_copy_data_file.F
modified:   model/src/ini_curvilinear_grid.F
modified:   model/src/ini_parms.F
modified:   model/src/packages_boot.F
modified:   pkg/bbl/bbl_readparms.F
modified:   pkg/cal/cal_readparms.F
modified:   pkg/diagnostics/diagnostics_readparms.F
modified:   pkg/exch2/w2_eeboot.F
modified:   pkg/exch2/w2_readparms.F
modified:   pkg/exf/exf_interp_read.F
modified:   pkg/exf/exf_readparms.F
modified:   pkg/kpp/kpp_readparms.F
modified:   pkg/mdsio/mdsio_facef_read.F
modified:   pkg/mdsio/mdsio_read_field.F
modified:   pkg/mdsio/mdsio_read_meta.F
modified:   pkg/salt_plume/salt_plume_readparms.F
modified:   pkg/seaice/seaice_readparms.F
What is the current behaviour?
See above
What is the new behaviour
Avoid Lustre interactions wherever possible by usign node-local /tmp, opening files with action='read' whenever read-only access is intended.
Does this PR introduce a breaking change?
The user needs to prepopulate /tmp on each compute node with various configuration and meta-data files.  Might be better to test for the existence of a given file under /tmp instead of forcing users to comply.  Let me know how you would like this to be implemented.
Other information:
Suggested addition to tag-index
(To avoid unnecessary merge conflicts, please don't update tag-index. One of the admins will do that when merging your pull request.)

Hi Dan, apologies for being a bit late to read and respond.  It was proposal-deadline madness for last coupe of weeks.
The speed-up tests that you are doing are super-helpful as we are spinning up towards the DYAMOND GEOS-MITgcm integrations.
Regarding the GLOBAL_SUM, I had a look at how we run the 1/12, 1/24, and 1/48 global configurations:
https://github.com/MITgcm-contrib/llc_hires/blob/master/llc_1080/code/CPP_EEOPTIONS.h https://github.com/MITgcm-contrib/llc_hires/blob/master/llc_1080/code/CPP_EEOPTIONS.h
https://github.com/MITgcm-contrib/llc_hires/blob/master/llc_2160/code/CPP_EEOPTIONS.h https://github.com/MITgcm-contrib/llc_hires/blob/master/llc_2160/code/CPP_EEOPTIONS.h
https://github.com/MITgcm-contrib/llc_hires/blob/master/llc_4320/code/CPP_EEOPTIONS.h https://github.com/MITgcm-contrib/llc_hires/blob/master/llc_4320/code/CPP_EEOPTIONS.h
and we had undefined all the GLOBAL_SUM flags, so I think we should be OK there, correct?
Second, regarding the reading of the initial configuration files, I think Bron or Chris (cc-ed) had noticed the same problem.
And the solution for the 1/48-deg simulations was addition of following option in CPP_EEOPTIONS.h:
C--   Flag defined for eeboot_minimal.F, eeset_parms.F and open_copy_data_file.F
C     to write STDOUT, STDERR and scratch files from process 0 only.
C WARNING: to use only when absolutely confident that the setup is working
C     since any message (error/warning/print) from any proc <> 0 will be lost.
#define SINGLE_DISK_IO
Does the SINGLE_DISK_IO fix the problem that you report below?
Third, another speed-up issue that we are grappling with is initialization of the model state, which requires
reading of large, Real*8 files that contain a complete description of the model’s prognostic state.
Bron wrote some parallel MPI IO code to do this, checked in here:
https://github.com/MITgcm-contrib/llc_hires/tree/master/llc_90/code-async https://github.com/MITgcm-contrib/llc_hires/tree/master/llc_90/code-async
with instructions for setting up here:
https://github.com/MITgcm-contrib/llc_hires/blob/master/llc_90/readme.txt https://github.com/MITgcm-contrib/llc_hires/blob/master/llc_90/readme.txtfollowing the comment line:
"# 30x30x96 configuration with Bron's latest asyncio”
Do you want to experiment with that to see if it makes a difference for initialization of your llc540 set-up?
Thanks, Dimitris

On Dec 7, 2020, at 2:11 PM, dkokron<EMAIL_ADDRESS>wrote:
What changes does this PR introduce?
Improved interaction with Pleiades Lustre file systems. This PR addresses several issues in the current code resulting in a 200 second savings during startup (~300s -> ~90s) for the llc_540 case.
Each MPI process creates and reads numerous scratch files in the case directory. I moved these to /tmp saving O(10^4) MDS hits
Each MPI process reads numerous small configuration files from the case directory. I moved these to /tmp saving O(10^4) MDS hits. Requires that the user pre-populate /tmp on each node. I accomplish this on pleiades using
pdsh -w /u/scicon/tools/bin/pbs_nodes $PBS_JOBID "cd $PWD; mkdir -p /tmp/namelist; /bin/cp data eedata data.{bbl,cal,diagnostics,exch2,exf,kpp,pkg,salt_plume,seaice} /tmp/namelist/"
The code uses the Fortran default action when opening files for read-only access. Fortran defaults to action=' READWRITE ' when opening files. If a user does not have write access (think shared boundary conditions), then the first attempt to access the file will fail. The fortran runtime then attempts to open the file action='read' which then succeeds. While this can be very fast, it depends greatly on how busy the Lustre meta-data server (MDS) is. Considering the MDS is a shared resource, all these extra MDS hits really just contribute extra load on an already burdened resource. I added action='read' to all of the open() statements where IOT indicated it would be useful.
Changed files
modified: eesupp/src/eeset_parms.F
modified: eesupp/src/open_copy_data_file.F
modified: model/src/ini_curvilinear_grid.F
modified: model/src/ini_parms.F
modified: model/src/packages_boot.F
modified: pkg/bbl/bbl_readparms.F
modified: pkg/cal/cal_readparms.F
modified: pkg/diagnostics/diagnostics_readparms.F
modified: pkg/exch2/w2_eeboot.F
modified: pkg/exch2/w2_readparms.F
modified: pkg/exf/exf_interp_read.F
modified: pkg/exf/exf_readparms.F
modified: pkg/kpp/kpp_readparms.F
modified: pkg/mdsio/mdsio_facef_read.F
modified: pkg/mdsio/mdsio_read_field.F
modified: pkg/mdsio/mdsio_read_meta.F
modified: pkg/salt_plume/salt_plume_readparms.F
modified: pkg/seaice/seaice_readparms.F
What is the current behaviour?
See above
What is the new behaviour
Avoid Lustre interactions wherever possible by usign node-local /tmp, opening files with action='read' whenever read-only access is intended.
Does this PR introduce a breaking change?
The user needs to prepopulate /tmp on each compute node with various configuration and meta-data files. Might be better to test for the existence of a given file under /tmp instead of forcing users to comply. Let me know how you would like this to be implemented.
Other information:
Suggested addition to tag-index
(To avoid unnecessary merge conflicts, please don't update tag-index. One of the admins will do that when merging your pull request.)
You can view, comment on, or merge this pull request online at:
https://github.com/MITgcm/MITgcm/pull/396 https://github.com/MITgcm/MITgcm/pull/396
Commit Summary
Read namelist files from /tmp. Requires that the user pre-populate /tmp on each node with
Open read-only files with action=read to avoid unnecessary Lustre MDS interatction
Open read-only files with action=read to avoid unnecessary Lustre MDS interatction; New routine MDS_FACEF_READ_RS2() similar to MDS_FACEF_READ_RS() but takes an open file unit instead of a fileName
Open tile file once for multiple reads, call new routine MDS_FACEF_READ_RS2()
Create and read scratch file in node-local /tmp; Read namelist files from /tmp. Requires that the user pre-populate /tmp on each node; Open read-only files with action=read to avoid unnecessary Lustre MDS interatction
File Changes
M eesupp/src/eeset_parms.F https://github.com/MITgcm/MITgcm/pull/396/files#diff-20e4a2651ec26ab9402305abecd0d1072ebb5cfa500af7a34aa0747c0a97523b (12)
M eesupp/src/open_copy_data_file.F https://github.com/MITgcm/MITgcm/pull/396/files#diff-f9ea395f06d1cc3cdb293d8d5a2d2a249976b424aa5195493a59723a47751fe5 (10)
M model/src/ini_curvilinear_grid.F https://github.com/MITgcm/MITgcm/pull/396/files#diff-13784cf2f79992c756fba30c37ee696c316503101ff0af6f74decaf53d5623d1 (99)
M model/src/ini_parms.F https://github.com/MITgcm/MITgcm/pull/396/files#diff-977e08a66d018113b62bd72230d9cc2448e55ef980e7112e6c1b6c36d2c3f12e (2)
M model/src/packages_boot.F https://github.com/MITgcm/MITgcm/pull/396/files#diff-6199f5d884feb0d72ad6a8ad1bda025a1bfcc380e1619659893458cd67c25827 (2)
M pkg/bbl/bbl_readparms.F https://github.com/MITgcm/MITgcm/pull/396/files#diff-b19ee2e66c67cf935f4f97d2d78eca825c1b8866c5583fe04a86dbe63b261e32 (2)
M pkg/cal/cal_readparms.F https://github.com/MITgcm/MITgcm/pull/396/files#diff-0b99ed7b36bae0c0bdc95c11e4787685983d43e6cf145812c31978c94ce9ede1 (2)
M pkg/diagnostics/diagnostics_readparms.F https://github.com/MITgcm/MITgcm/pull/396/files#diff-930718360b6e7ff0b9eefafc9dc2ab3f8ba90807366ce68d0208d08b3b08a2c9 (2)
M pkg/exch2/w2_eeboot.F https://github.com/MITgcm/MITgcm/pull/396/files#diff-ae13e3293fb2ac61a43ff62448177dbff06123f577717c47d962be59716ca204 (2)
M pkg/exch2/w2_readparms.F https://github.com/MITgcm/MITgcm/pull/396/files#diff-99de1b24dc4fe5f4acc81a164bb4a957b18bd5a947381a8fb2d9ef599b440b3a (2)
M pkg/exf/exf_interp_read.F https://github.com/MITgcm/MITgcm/pull/396/files#diff-6a262c2273a13a2f3e433e4f9c544c2af4c76925aa1241e7727ec894a896a106 (2)
M pkg/exf/exf_readparms.F https://github.com/MITgcm/MITgcm/pull/396/files#diff-f42875521a1b4309eaab491785303df68883fba5efa5b7e903688305599b98fb (2)
M pkg/kpp/kpp_readparms.F https://github.com/MITgcm/MITgcm/pull/396/files#diff-d923a2ede2f63fd32b346702d84cd9e81f279317f0ea2bd27cefc7a69b035190 (2)
M pkg/mdsio/mdsio_facef_read.F https://github.com/MITgcm/MITgcm/pull/396/files#diff-4e09a8ce855c5c0f2a8ab0551ca030ffafad704d95c7b70e8dfc31a36f6cecc2 (146)
M pkg/mdsio/mdsio_read_field.F https://github.com/MITgcm/MITgcm/pull/396/files#diff-d8e5e606b4b9565454fbcc72bf963050a1980f793d07724c073258c855a9fb17 (6)
M pkg/mdsio/mdsio_read_meta.F https://github.com/MITgcm/MITgcm/pull/396/files#diff-48598b8beb59f810d9185ff9bc3a831b5b7a354e8d7fd6d069f534f20be42385 (3)
M pkg/salt_plume/salt_plume_readparms.F https://github.com/MITgcm/MITgcm/pull/396/files#diff-167614ff7104dd4d06ef3c7da72a0a1a538de5bb1cb4a927bc996f47f4d785c8 (2)
M pkg/seaice/seaice_readparms.F https://github.com/MITgcm/MITgcm/pull/396/files#diff-412afb21498b152e151475fed1582304c02fae146a592d24f7ea2a8b38dcf9f6 (2)
Patch Links:
https://github.com/MITgcm/MITgcm/pull/396.patch https://github.com/MITgcm/MITgcm/pull/396.patch
https://github.com/MITgcm/MITgcm/pull/396.diff https://github.com/MITgcm/MITgcm/pull/396.diff
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub https://github.com/MITgcm/MITgcm/pull/396, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABH7CSLAIYAR3ZFUAPNCQKLSTVHKLANCNFSM4URCYCZA.

Dimitris,
Regarding optimization of the global sum, yes, setting all the GLOBAL_SUM flags to undefined is the approach I recommend at this point.
I will investigate setting ‘define SINGLE_DISK_IO’.  Thanks for the tip!
Using asyncio for the llc_540 case would be overkill as it isn’t spending much time dropping diagnostics, not as currently configured anyway.
Dan
From: Dimitris Menemenlis<EMAIL_ADDRESS>Date: Tuesday, December 8, 2020 at 12:39 PM
To: MITgcm/MITgcm<EMAIL_ADDRESS>Cc: MITgcm/MITgcm<EMAIL_ADDRESS>Subscribed<EMAIL_ADDRESS>"Zhang, Hong (JPL-398K)[JPL Employee]"<EMAIL_ADDRESS>"Kokron, Daniel S. (ARC-606.2)[InuTeq, LLC]"<EMAIL_ADDRESS>"Nelson, Bron C. (ARC-TN)[InuTeq, LLC]"<EMAIL_ADDRESS>"Henze, Christopher E. (ARC-TNC)"<EMAIL_ADDRESS>Subject: [EXTERNAL] Re: [MITgcm/MITgcm] Dkokron/reduce startup time (#396)
Hi Dan, apologies for being a bit late to read and respond.  It was proposal-deadline madness for last coupe of weeks.
The speed-up tests that you are doing are super-helpful as we are spinning up towards the DYAMOND GEOS-MITgcm integrations.
Regarding the GLOBAL_SUM, I had a look at how we run the 1/12, 1/24, and 1/48 global configurations:
https://github.com/MITgcm-contrib/llc_hires/blob/master/llc_1080/code/CPP_EEOPTIONS.hhttps://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMITgcm-contrib%2Fllc_hires%2Fblob%2Fmaster%2Fllc_1080%2Fcode%2FCPP_EEOPTIONS.h&data=04|01|daniel.s.kokron%40nasa.gov|6deafdc5868f401bd49608d89ba89c3c|7005d45845be48ae8140d43da96dd17b|0|0|637430495758879971|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=F7d1ZdjEKtx0nsxUhkTL8J8MtZdt8JXFldX14kf4L%2B0%3D&reserved=0
https://github.com/MITgcm-contrib/llc_hires/blob/master/llc_2160/code/CPP_EEOPTIONS.hhttps://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMITgcm-contrib%2Fllc_hires%2Fblob%2Fmaster%2Fllc_2160%2Fcode%2FCPP_EEOPTIONS.h&data=04|01|daniel.s.kokron%40nasa.gov|6deafdc5868f401bd49608d89ba89c3c|7005d45845be48ae8140d43da96dd17b|0|0|637430495758889925|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=Uwix981xFpL8TTwi594uQQD7vemcFQv4uvcUMuSSc0g%3D&reserved=0
https://github.com/MITgcm-contrib/llc_hires/blob/master/llc_4320/code/CPP_EEOPTIONS.hhttps://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMITgcm-contrib%2Fllc_hires%2Fblob%2Fmaster%2Fllc_4320%2Fcode%2FCPP_EEOPTIONS.h&data=04|01|daniel.s.kokron%40nasa.gov|6deafdc5868f401bd49608d89ba89c3c|7005d45845be48ae8140d43da96dd17b|0|0|637430495758889925|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=gdwC3Kg1AGwKezZBRElthZe3uPpeNmrJ8xYdlXmkGNY%3D&reserved=0
and we had undefined all the GLOBAL_SUM flags, so I think we should be OK there, correct?
Second, regarding the reading of the initial configuration files, I think Bron or Chris (cc-ed) had noticed the same problem.
And the solution for the 1/48-deg simulations was addition of following option in CPP_EEOPTIONS.h:
C--   Flag defined for eeboot_minimal.F, eeset_parms.F and open_copy_data_file.F
C     to write STDOUT, STDERR and scratch files from process 0 only.
C WARNING: to use only when absolutely confident that the setup is working
C     since any message (error/warning/print) from any proc <> 0 will be lost.
#define SINGLE_DISK_IO
Does the SINGLE_DISK_IO fix the problem that you report below?
Third, another speed-up issue that we are grappling with is initialization of the model state, which requires
reading of large, Real*8 files that contain a complete description of the model’s prognostic state.
Bron wrote some parallel MPI IO code to do this, checked in here:
https://github.com/MITgcm-contrib/llc_hires/tree/master/llc_90/code-asynchttps://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMITgcm-contrib%2Fllc_hires%2Ftree%2Fmaster%2Fllc_90%2Fcode-async&data=04|01|daniel.s.kokron%40nasa.gov|6deafdc5868f401bd49608d89ba89c3c|7005d45845be48ae8140d43da96dd17b|0|0|637430495758899873|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=1AAOOnlBJN6tO3ba1dL6JCR1gDQJ8iki8CCuCM%2FdtMY%3D&reserved=0
with instructions for setting up here:
https://github.com/MITgcm-contrib/llc_hires/blob/master/llc_90/readme.txthttps://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMITgcm-contrib%2Fllc_hires%2Fblob%2Fmaster%2Fllc_90%2Freadme.txt&data=04|01|daniel.s.kokron%40nasa.gov|6deafdc5868f401bd49608d89ba89c3c|7005d45845be48ae8140d43da96dd17b|0|0|637430495758899873|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=oOrCg8swDkIsH1KrRR7ejI8XQJvmhE5GCrZJtGaIMoQ%3D&reserved=0
following the comment line:
"# 30x30x96 configuration with Bron's latest asyncio”
Do you want to experiment with that to see if it makes a difference for initialization of your llc540 set-up?
Thanks, Dimitris
On Dec 7, 2020, at 2:11 PM, dkokron <notifications<EMAIL_ADDRESS>wrote:
What changes does this PR introduce?
Improved interaction with Pleiades Lustre file systems. This PR addresses several issues in the current code resulting in a 200 second savings during startup (~300s -> ~90s) for the llc_540 case.

Each MPI process creates and reads numerous scratch files in the case directory. I moved these to /tmp saving O(10^4) MDS hits
Each MPI process reads numerous small configuration files from the case directory. I moved these to /tmp saving O(10^4) MDS hits. Requires that the user pre-populate /tmp on each node. I accomplish this on pleiades using
pdsh -w /u/scicon/tools/bin/pbs_nodes $PBS_JOBID "cd $PWD; mkdir -p /tmp/namelist; /bin/cp data eedata data.{bbl,cal,diagnostics,exch2,exf,kpp,pkg,salt_plume,seaice} /tmp/namelist/"
The code uses the Fortran default action when opening files for read-only access. Fortran defaults to action=' READWRITE ' when opening files. If a user does not have write access (think shared boundary conditions), then the first attempt to access the file will fail. The fortran runtime then attempts to open the file action='read' which then succeeds. While this can be very fast, it depends greatly on how busy the Lustre meta-data server (MDS) is. Considering the MDS is a shared resource, all these extra MDS hits really just contribute extra load on an already burdened resource. I added action='read' to all of the open() statements where IOT indicated it would be useful.
Changed files
modified: eesupp/src/eeset_parms.F
modified: eesupp/src/open_copy_data_file.F
modified: model/src/ini_curvilinear_grid.F
modified: model/src/ini_parms.F
modified: model/src/packages_boot.F
modified: pkg/bbl/bbl_readparms.F
modified: pkg/cal/cal_readparms.F
modified: pkg/diagnostics/diagnostics_readparms.F
modified: pkg/exch2/w2_eeboot.F
modified: pkg/exch2/w2_readparms.F
modified: pkg/exf/exf_interp_read.F
modified: pkg/exf/exf_readparms.F
modified: pkg/kpp/kpp_readparms.F
modified: pkg/mdsio/mdsio_facef_read.F
modified: pkg/mdsio/mdsio_read_field.F
modified: pkg/mdsio/mdsio_read_meta.F
modified: pkg/salt_plume/salt_plume_readparms.F
modified: pkg/seaice/seaice_readparms.F
What is the current behaviour?
See above
What is the new behaviour
Avoid Lustre interactions wherever possible by usign node-local /tmp, opening files with action='read' whenever read-only access is intended.
Does this PR introduce a breaking change?
The user needs to prepopulate /tmp on each compute node with various configuration and meta-data files. Might be better to test for the existence of a given file under /tmp instead of forcing users to comply. Let me know how you would like this to be implemented.
Other information:
Suggested addition to tag-index
(To avoid unnecessary merge conflicts, please don't update tag-index. One of the admins will do that when merging your pull request.)

You can view, comment on, or merge this pull request online at:
https://github.com/MITgcm/MITgcm/pull/396https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMITgcm%2FMITgcm%2Fpull%2F396&data=04|01|daniel.s.kokron%40nasa.gov|6deafdc5868f401bd49608d89ba89c3c|7005d45845be48ae8140d43da96dd17b|0|0|637430495758909827|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=pkAbwwbN7W%2Frms6Zq9FTgL5aIsPqgX4VFCQrS9XokTw%3D&reserved=0
Commit Summary

Read namelist files from /tmp. Requires that the user pre-populate /tmp on each node with
Open read-only files with action=read to avoid unnecessary Lustre MDS interatction
Open read-only files with action=read to avoid unnecessary Lustre MDS interatction; New routine MDS_FACEF_READ_RS2() similar to MDS_FACEF_READ_RS() but takes an open file unit instead of a fileName
Open tile file once for multiple reads, call new routine MDS_FACEF_READ_RS2()
Create and read scratch file in node-local /tmp; Read namelist files from /tmp. Requires that the user pre-populate /tmp on each node; Open read-only files with action=read to avoid unnecessary Lustre MDS interatction

File Changes

M eesupp/src/eeset_parms.Fhttps://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMITgcm%2FMITgcm%2Fpull%2F396%2Ffiles%23diff-20e4a2651ec26ab9402305abecd0d1072ebb5cfa500af7a34aa0747c0a97523b&data=04|01|daniel.s.kokron%40nasa.gov|6deafdc5868f401bd49608d89ba89c3c|7005d45845be48ae8140d43da96dd17b|0|0|637430495758909827|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=FHR%2B0gTAivgJnig9R1UTPuKZcuofqQDz6p83UM04el0%3D&reserved=0 (12)
M eesupp/src/open_copy_data_file.Fhttps://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMITgcm%2FMITgcm%2Fpull%2F396%2Ffiles%23diff-f9ea395f06d1cc3cdb293d8d5a2d2a249976b424aa5195493a59723a47751fe5&data=04|01|daniel.s.kokron%40nasa.gov|6deafdc5868f401bd49608d89ba89c3c|7005d45845be48ae8140d43da96dd17b|0|0|637430495758919782|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=hw2iMYxM%2Bo2GuoKtHqgseUS69T5puMnG0i63dGBHYxs%3D&reserved=0 (10)
M model/src/ini_curvilinear_grid.Fhttps://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMITgcm%2FMITgcm%2Fpull%2F396%2Ffiles%23diff-13784cf2f79992c756fba30c37ee696c316503101ff0af6f74decaf53d5623d1&data=04|01|daniel.s.kokron%40nasa.gov|6deafdc5868f401bd49608d89ba89c3c|7005d45845be48ae8140d43da96dd17b|0|0|637430495758919782|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=QMxyj4oAKZj8bq7hCBCAeJFhBGiCXphIj9VBvahKNYo%3D&reserved=0 (99)
M model/src/ini_parms.Fhttps://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMITgcm%2FMITgcm%2Fpull%2F396%2Ffiles%23diff-977e08a66d018113b62bd72230d9cc2448e55ef980e7112e6c1b6c36d2c3f12e&data=04|01|daniel.s.kokron%40nasa.gov|6deafdc5868f401bd49608d89ba89c3c|7005d45845be48ae8140d43da96dd17b|0|0|637430495758929742|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=e57adZx0p%2FbcllUV9Szf0%2BcUEAyFRW08ZZT7i7Qtyx8%3D&reserved=0 (2)
M model/src/packages_boot.Fhttps://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMITgcm%2FMITgcm%2Fpull%2F396%2Ffiles%23diff-6199f5d884feb0d72ad6a8ad1bda025a1bfcc380e1619659893458cd67c25827&data=04|01|daniel.s.kokron%40nasa.gov|6deafdc5868f401bd49608d89ba89c3c|7005d45845be48ae8140d43da96dd17b|0|0|637430495758929742|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=eeJXMKjIjYl%2Bku09hE2K6pLm9NYEM6nvHK9wV7LTQzY%3D&reserved=0 (2)
M pkg/bbl/bbl_readparms.Fhttps://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMITgcm%2FMITgcm%2Fpull%2F396%2Ffiles%23diff-b19ee2e66c67cf935f4f97d2d78eca825c1b8866c5583fe04a86dbe63b261e32&data=04|01|daniel.s.kokron%40nasa.gov|6deafdc5868f401bd49608d89ba89c3c|7005d45845be48ae8140d43da96dd17b|0|0|637430495758939697|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=uehnU0yVLf5idjXIgH17jGZ2Ixo29panLKmQnH6u6c4%3D&reserved=0 (2)
M pkg/cal/cal_readparms.Fhttps://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMITgcm%2FMITgcm%2Fpull%2F396%2Ffiles%23diff-0b99ed7b36bae0c0bdc95c11e4787685983d43e6cf145812c31978c94ce9ede1&data=04|01|daniel.s.kokron%40nasa.gov|6deafdc5868f401bd49608d89ba89c3c|7005d45845be48ae8140d43da96dd17b|0|0|637430495758939697|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=kB%2Be0z7tAGpXkEJsBbSCAi2xegDfsT%2FNb0cYApB7LEo%3D&reserved=0 (2)
M pkg/diagnostics/diagnostics_readparms.Fhttps://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMITgcm%2FMITgcm%2Fpull%2F396%2Ffiles%23diff-930718360b6e7ff0b9eefafc9dc2ab3f8ba90807366ce68d0208d08b3b08a2c9&data=04|01|daniel.s.kokron%40nasa.gov|6deafdc5868f401bd49608d89ba89c3c|7005d45845be48ae8140d43da96dd17b|0|0|637430495758949655|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=RZ%2BTW%2FHnWYrIQ2vsHDok6SdVoficCaYrE13hXTtZZcE%3D&reserved=0 (2)
M pkg/exch2/w2_eeboot.Fhttps://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMITgcm%2FMITgcm%2Fpull%2F396%2Ffiles%23diff-ae13e3293fb2ac61a43ff62448177dbff06123f577717c47d962be59716ca204&data=04|01|daniel.s.kokron%40nasa.gov|6deafdc5868f401bd49608d89ba89c3c|7005d45845be48ae8140d43da96dd17b|0|0|637430495758949655|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=rQOqwH%2FO0%2BhLsIYuR6Nq0JJi8vHPqjd9mZFOaVkI9Y8%3D&reserved=0 (2)
M pkg/exch2/w2_readparms.Fhttps://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMITgcm%2FMITgcm%2Fpull%2F396%2Ffiles%23diff-99de1b24dc4fe5f4acc81a164bb4a957b18bd5a947381a8fb2d9ef599b440b3a&data=04|01|daniel.s.kokron%40nasa.gov|6deafdc5868f401bd49608d89ba89c3c|7005d45845be48ae8140d43da96dd17b|0|0|637430495758959620|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=hCBzIi6TNrBftJFm%2BJOim%2F2RnGC%2FDqC3NQCI5QgX6ok%3D&reserved=0 (2)
M pkg/exf/exf_interp_read.Fhttps://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMITgcm%2FMITgcm%2Fpull%2F396%2Ffiles%23diff-6a262c2273a13a2f3e433e4f9c544c2af4c76925aa1241e7727ec894a896a106&data=04|01|daniel.s.kokron%40nasa.gov|6deafdc5868f401bd49608d89ba89c3c|7005d45845be48ae8140d43da96dd17b|0|0|637430495758959620|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=ZdHQpg2mmJSzLtCs0u1WQoq7x4py0lbnLKrqDRxsWpU%3D&reserved=0 (2)
M pkg/exf/exf_readparms.Fhttps://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMITgcm%2FMITgcm%2Fpull%2F396%2Ffiles%23diff-f42875521a1b4309eaab491785303df68883fba5efa5b7e903688305599b98fb&data=04|01|daniel.s.kokron%40nasa.gov|6deafdc5868f401bd49608d89ba89c3c|7005d45845be48ae8140d43da96dd17b|0|0|637430495758969579|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=3WvGxVbHbyOVupkDYDLTpPCpAixI%2FfOs%2BKzabeJuJDI%3D&reserved=0 (2)
M pkg/kpp/kpp_readparms.Fhttps://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMITgcm%2FMITgcm%2Fpull%2F396%2Ffiles%23diff-d923a2ede2f63fd32b346702d84cd9e81f279317f0ea2bd27cefc7a69b035190&data=04|01|daniel.s.kokron%40nasa.gov|6deafdc5868f401bd49608d89ba89c3c|7005d45845be48ae8140d43da96dd17b|0|0|637430495758979520|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=hi6MT%2BskvcNYip0S5NKGcA80zt66VZl577IvD0iM9D4%3D&reserved=0 (2)
M pkg/mdsio/mdsio_facef_read.Fhttps://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMITgcm%2FMITgcm%2Fpull%2F396%2Ffiles%23diff-4e09a8ce855c5c0f2a8ab0551ca030ffafad704d95c7b70e8dfc31a36f6cecc2&data=04|01|daniel.s.kokron%40nasa.gov|6deafdc5868f401bd49608d89ba89c3c|7005d45845be48ae8140d43da96dd17b|0|0|637430495758979520|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=CWJYGFff4fFfAc5Flu3Vi%2B05gzTIU%2BCdotKQ9dBo4aE%3D&reserved=0 (146)
M pkg/mdsio/mdsio_read_field.Fhttps://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMITgcm%2FMITgcm%2Fpull%2F396%2Ffiles%23diff-d8e5e606b4b9565454fbcc72bf963050a1980f793d07724c073258c855a9fb17&data=04|01|daniel.s.kokron%40nasa.gov|6deafdc5868f401bd49608d89ba89c3c|7005d45845be48ae8140d43da96dd17b|0|0|637430495758989586|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=s3e8F5X%2ByfaIuw9F%2Fla86hmdXj19v23yICT3r3w7Acw%3D&reserved=0 (6)
M pkg/mdsio/mdsio_read_meta.Fhttps://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMITgcm%2FMITgcm%2Fpull%2F396%2Ffiles%23diff-48598b8beb59f810d9185ff9bc3a831b5b7a354e8d7fd6d069f534f20be42385&data=04|01|daniel.s.kokron%40nasa.gov|6deafdc5868f401bd49608d89ba89c3c|7005d45845be48ae8140d43da96dd17b|0|0|637430495758989586|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=17Zb52ZIFS%2FhOaJ737Zefvl2bs7ovZoFutQOdoPLoW0%3D&reserved=0 (3)
M pkg/salt_plume/salt_plume_readparms.Fhttps://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMITgcm%2FMITgcm%2Fpull%2F396%2Ffiles%23diff-167614ff7104dd4d06ef3c7da72a0a1a538de5bb1cb4a927bc996f47f4d785c8&data=04|01|daniel.s.kokron%40nasa.gov|6deafdc5868f401bd49608d89ba89c3c|7005d45845be48ae8140d43da96dd17b|0|0|637430495758999433|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=m7EffliLUukHN4%2BpdCzrCISlU5uX%2BnM2py3IvZYixMI%3D&reserved=0 (2)
M pkg/seaice/seaice_readparms.Fhttps://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMITgcm%2FMITgcm%2Fpull%2F396%2Ffiles%23diff-412afb21498b152e151475fed1582304c02fae146a592d24f7ea2a8b38dcf9f6&data=04|01|daniel.s.kokron%40nasa.gov|6deafdc5868f401bd49608d89ba89c3c|7005d45845be48ae8140d43da96dd17b|0|0|637430495758999433|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=6vmD8VK60%2Fybw7wg3%2FhHnDsH9q95G77iw%2B0rgzSQ3cU%3D&reserved=0 (2)

Patch Links:

https://github.com/MITgcm/MITgcm/pull/396.patchhttps://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMITgcm%2FMITgcm%2Fpull%2F396.patch&data=04|01|daniel.s.kokron%40nasa.gov|6deafdc5868f401bd49608d89ba89c3c|7005d45845be48ae8140d43da96dd17b|0|0|637430495759009388|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=Syu082y7TzP13FI0iSdKsavAyMYq5rol%2FgEhZ0peJ3k%3D&reserved=0
https://github.com/MITgcm/MITgcm/pull/396.diffhttps://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMITgcm%2FMITgcm%2Fpull%2F396.diff&data=04|01|daniel.s.kokron%40nasa.gov|6deafdc5868f401bd49608d89ba89c3c|7005d45845be48ae8140d43da96dd17b|0|0|637430495759009388|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=ca8YWx3bz5r97OgMBfWqhaVQNLxouzPV0K%2FUoejIIms%3D&reserved=0
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHubhttps://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMITgcm%2FMITgcm%2Fpull%2F396&data=04|01|daniel.s.kokron%40nasa.gov|6deafdc5868f401bd49608d89ba89c3c|7005d45845be48ae8140d43da96dd17b|0|0|637430495759019355|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=7J%2B6FXjbTHxwlUJeLNWo6teJcyLW%2B%2B4kStqIwzU%2FifA%3D&reserved=0, or unsubscribehttps://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FABH7CSLAIYAR3ZFUAPNCQKLSTVHKLANCNFSM4URCYCZA&data=04|01|daniel.s.kokron%40nasa.gov|6deafdc5868f401bd49608d89ba89c3c|7005d45845be48ae8140d43da96dd17b|0|0|637430495759019355|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=HS6M3HjrocQai3DloQSa%2FWhyohhZx4C1CtbHMBOjV%2F0%3D&reserved=0.

Dan -

Using asyncio for the llc_540 case would be overkill as it isn’t
spending much time dropping diagnostics

I'm kinda coming on in the middle of this conversation, but note that Dimitris is talking about two different things:  there is the asyncio code for doing output, and then there is the (not asynchronous) i/o code for doing input.  Chris and I did the output stuff a while back because that was a bottleneck for the llc-4320 runs.  More recently, I wrote some code to do the input initialization using MPI-IO since the long startup times were impacting the development/debug of the coupled code. [It's not nearly as fast as the full-custom output routines, but it was a lot faster/easier to write, and you only do the input once.]
It appears that Dimitris is referring to the latter rather than the former.  Although it must be admitted that I've never gotten Dimitris to state that he's ever even tried the code, let alone whether or not it works, and if so how fast it is.
--
Bron Campbell Nelson<EMAIL_ADDRESS>These statements are my own, not those of NASA or ASRC
We trained hard, but it seemed that every time we were beginning to form up
into teams we would be reorganized [...] I was to learn later in life that, perhaps
because we are so good at organizing, we tend as a nation to meet any new
situation by reorganizing; and a wonderful method it can be for creating the
illusion of progress while producing confusion, inefficiency and demoralization.
Charlton Ogburn  (often erroneously attributed to Petronius Arbiter)

From: Kokron, Daniel S. (ARC-606.2)[InuTeq, LLC]<EMAIL_ADDRESS>Sent: Tuesday, December 8, 2020 10:54 AM
To: Dimitris Menemenlis; MITgcm/MITgcm
Cc: MITgcm/MITgcm; Subscribed; Zhang, Hong (JPL-398K)[JPL Employee]; Nelson, Bron C. (ARC-TN)[InuTeq, LLC]; Henze, Christopher E. (ARC-TNC)
Subject: Re: [EXTERNAL] Re: [MITgcm/MITgcm] Dkokron/reduce startup time (#396)
Dimitris,
Regarding optimization of the global sum, yes, setting all the GLOBAL_SUM flags to undefined is the approach I recommend at this point.
I will investigate setting ‘define SINGLE_DISK_IO’.  Thanks for the tip!
Using asyncio for the llc_540 case would be overkill as it isn’t spending much time dropping diagnostics, not as currently configured anyway.
Dan
From: Dimitris Menemenlis<EMAIL_ADDRESS>Date: Tuesday, December 8, 2020 at 12:39 PM
To: MITgcm/MITgcm<EMAIL_ADDRESS>Cc: MITgcm/MITgcm<EMAIL_ADDRESS>Subscribed<EMAIL_ADDRESS>"Zhang, Hong (JPL-398K)[JPL Employee]"<EMAIL_ADDRESS>"Kokron, Daniel S. (ARC-606.2)[InuTeq, LLC]"<EMAIL_ADDRESS>"Nelson, Bron C. (ARC-TN)[InuTeq, LLC]"<EMAIL_ADDRESS>"Henze, Christopher E. (ARC-TNC)"<EMAIL_ADDRESS>Subject: [EXTERNAL] Re: [MITgcm/MITgcm] Dkokron/reduce startup time (#396)
Hi Dan, apologies for being a bit late to read and respond.  It was proposal-deadline madness for last coupe of weeks.
The speed-up tests that you are doing are super-helpful as we are spinning up towards the DYAMOND GEOS-MITgcm integrations.
Regarding the GLOBAL_SUM, I had a look at how we run the 1/12, 1/24, and 1/48 global configurations:
https://github.com/MITgcm-contrib/llc_hires/blob/master/llc_1080/code/CPP_EEOPTIONS.hhttps://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMITgcm-contrib%2Fllc_hires%2Fblob%2Fmaster%2Fllc_1080%2Fcode%2FCPP_EEOPTIONS.h&data=04|01|bron.c.nelson%40nasa.gov|ceb5cf6c84d541ede5dc08d89baac0a1|7005d45845be48ae8140d43da96dd17b|0|0|637430504959113580|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=63f%2BhaBsd%2B0J9ycDmGg6Li%2BOdTnHW6GXUfTSfRJxQwI%3D&reserved=0
https://github.com/MITgcm-contrib/llc_hires/blob/master/llc_2160/code/CPP_EEOPTIONS.hhttps://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMITgcm-contrib%2Fllc_hires%2Fblob%2Fmaster%2Fllc_2160%2Fcode%2FCPP_EEOPTIONS.h&data=04|01|bron.c.nelson%40nasa.gov|ceb5cf6c84d541ede5dc08d89baac0a1|7005d45845be48ae8140d43da96dd17b|0|0|637430504959123537|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=H6BQJiXH6slPUEVFYyK0aTz15Iy6XP64JhJc5nndiIg%3D&reserved=0
https://github.com/MITgcm-contrib/llc_hires/blob/master/llc_4320/code/CPP_EEOPTIONS.hhttps://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMITgcm-contrib%2Fllc_hires%2Fblob%2Fmaster%2Fllc_4320%2Fcode%2FCPP_EEOPTIONS.h&data=04|01|bron.c.nelson%40nasa.gov|ceb5cf6c84d541ede5dc08d89baac0a1|7005d45845be48ae8140d43da96dd17b|0|0|637430504959133495|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=Wy4uF0T1ToqOl07I7cZsYViI3Whe9dlJXvuF1YmnHbo%3D&reserved=0
and we had undefined all the GLOBAL_SUM flags, so I think we should be OK there, correct?
Second, regarding the reading of the initial configuration files, I think Bron or Chris (cc-ed) had noticed the same problem.
And the solution for the 1/48-deg simulations was addition of following option in CPP_EEOPTIONS.h:
C--   Flag defined for eeboot_minimal.F, eeset_parms.F and open_copy_data_file.F
C     to write STDOUT, STDERR and scratch files from process 0 only.
C WARNING: to use only when absolutely confident that the setup is working
C     since any message (error/warning/print) from any proc <> 0 will be lost.
#define SINGLE_DISK_IO
Does the SINGLE_DISK_IO fix the problem that you report below?
Third, another speed-up issue that we are grappling with is initialization of the model state, which requires
reading of large, Real*8 files that contain a complete description of the model’s prognostic state.
Bron wrote some parallel MPI IO code to do this, checked in here:
https://github.com/MITgcm-contrib/llc_hires/tree/master/llc_90/code-asynchttps://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMITgcm-contrib%2Fllc_hires%2Ftree%2Fmaster%2Fllc_90%2Fcode-async&data=04|01|bron.c.nelson%40nasa.gov|ceb5cf6c84d541ede5dc08d89baac0a1|7005d45845be48ae8140d43da96dd17b|0|0|637430504959133495|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=ffHViHl4vYKksagX11yqMTwW%2BNV08VVzUsZs1JJL5ho%3D&reserved=0
with instructions for setting up here:
https://github.com/MITgcm-contrib/llc_hires/blob/master/llc_90/readme.txthttps://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMITgcm-contrib%2Fllc_hires%2Fblob%2Fmaster%2Fllc_90%2Freadme.txt&data=04|01|bron.c.nelson%40nasa.gov|ceb5cf6c84d541ede5dc08d89baac0a1|7005d45845be48ae8140d43da96dd17b|0|0|637430504959143452|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=esoTHhm5X8cvvqaiiZvvN5swBaUvGv9HWncsLd8OJSc%3D&reserved=0
following the comment line:
"# 30x30x96 configuration with Bron's latest asyncio”
Do you want to experiment with that to see if it makes a difference for initialization of your llc540 set-up?
Thanks, Dimitris
On Dec 7, 2020, at 2:11 PM, dkokron <notifications<EMAIL_ADDRESS>wrote:
What changes does this PR introduce?
Improved interaction with Pleiades Lustre file systems. This PR addresses several issues in the current code resulting in a 200 second savings during startup (~300s -> ~90s) for the llc_540 case.

Each MPI process creates and reads numerous scratch files in the case directory. I moved these to /tmp saving O(10^4) MDS hits
Each MPI process reads numerous small configuration files from the case directory. I moved these to /tmp saving O(10^4) MDS hits. Requires that the user pre-populate /tmp on each node. I accomplish this on pleiades using
pdsh -w /u/scicon/tools/bin/pbs_nodes $PBS_JOBID "cd $PWD; mkdir -p /tmp/namelist; /bin/cp data eedata data.{bbl,cal,diagnostics,exch2,exf,kpp,pkg,salt_plume,seaice} /tmp/namelist/"
The code uses the Fortran default action when opening files for read-only access. Fortran defaults to action=' READWRITE ' when opening files. If a user does not have write access (think shared boundary conditions), then the first attempt to access the file will fail. The fortran runtime then attempts to open the file action='read' which then succeeds. While this can be very fast, it depends greatly on how busy the Lustre meta-data server (MDS) is. Considering the MDS is a shared resource, all these extra MDS hits really just contribute extra load on an already burdened resource. I added action='read' to all of the open() statements where IOT indicated it would be useful.
Changed files
modified: eesupp/src/eeset_parms.F
modified: eesupp/src/open_copy_data_file.F
modified: model/src/ini_curvilinear_grid.F
modified: model/src/ini_parms.F
modified: model/src/packages_boot.F
modified: pkg/bbl/bbl_readparms.F
modified: pkg/cal/cal_readparms.F
modified: pkg/diagnostics/diagnostics_readparms.F
modified: pkg/exch2/w2_eeboot.F
modified: pkg/exch2/w2_readparms.F
modified: pkg/exf/exf_interp_read.F
modified: pkg/exf/exf_readparms.F
modified: pkg/kpp/kpp_readparms.F
modified: pkg/mdsio/mdsio_facef_read.F
modified: pkg/mdsio/mdsio_read_field.F
modified: pkg/mdsio/mdsio_read_meta.F
modified: pkg/salt_plume/salt_plume_readparms.F
modified: pkg/seaice/seaice_readparms.F
What is the current behaviour?
See above
What is the new behaviour
Avoid Lustre interactions wherever possible by usign node-local /tmp, opening files with action='read' whenever read-only access is intended.
Does this PR introduce a breaking change?
The user needs to prepopulate /tmp on each compute node with various configuration and meta-data files. Might be better to test for the existence of a given file under /tmp instead of forcing users to comply. Let me know how you would like this to be implemented.
Other information:
Suggested addition to tag-index
(To avoid unnecessary merge conflicts, please don't update tag-index. One of the admins will do that when merging your pull request.)

You can view, comment on, or merge this pull request online at:
https://github.com/MITgcm/MITgcm/pull/396https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMITgcm%2FMITgcm%2Fpull%2F396&data=04|01|bron.c.nelson%40nasa.gov|ceb5cf6c84d541ede5dc08d89baac0a1|7005d45845be48ae8140d43da96dd17b|0|0|637430504959143452|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=mekBVd6RA2hnI34DtNm0FqfPxIIwOHXKn0jZ1xLdqxc%3D&reserved=0
Commit Summary

Read namelist files from /tmp. Requires that the user pre-populate /tmp on each node with
Open read-only files with action=read to avoid unnecessary Lustre MDS interatction
Open read-only files with action=read to avoid unnecessary Lustre MDS interatction; New routine MDS_FACEF_READ_RS2() similar to MDS_FACEF_READ_RS() but takes an open file unit instead of a fileName
Open tile file once for multiple reads, call new routine MDS_FACEF_READ_RS2()
Create and read scratch file in node-local /tmp; Read namelist files from /tmp. Requires that the user pre-populate /tmp on each node; Open read-only files with action=read to avoid unnecessary Lustre MDS interatction

File Changes

M eesupp/src/eeset_parms.Fhttps://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMITgcm%2FMITgcm%2Fpull%2F396%2Ffiles%23diff-20e4a2651ec26ab9402305abecd0d1072ebb5cfa500af7a34aa0747c0a97523b&data=04|01|bron.c.nelson%40nasa.gov|ceb5cf6c84d541ede5dc08d89baac0a1|7005d45845be48ae8140d43da96dd17b|0|0|637430504959153415|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=hn8%2FU2mQ17kSWvxe91t2xPaJjHS%2BhY5L%2FyqMoKNCk3s%3D&reserved=0 (12)
M eesupp/src/open_copy_data_file.Fhttps://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMITgcm%2FMITgcm%2Fpull%2F396%2Ffiles%23diff-f9ea395f06d1cc3cdb293d8d5a2d2a249976b424aa5195493a59723a47751fe5&data=04|01|bron.c.nelson%40nasa.gov|ceb5cf6c84d541ede5dc08d89baac0a1|7005d45845be48ae8140d43da96dd17b|0|0|637430504959163367|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=hN6cvLvdT%2BCy4uFBkPJOfF4qOcCv%2FjZAFBgUVI%2F5%2BWA%3D&reserved=0 (10)
M model/src/ini_curvilinear_grid.Fhttps://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMITgcm%2FMITgcm%2Fpull%2F396%2Ffiles%23diff-13784cf2f79992c756fba30c37ee696c316503101ff0af6f74decaf53d5623d1&data=04|01|bron.c.nelson%40nasa.gov|ceb5cf6c84d541ede5dc08d89baac0a1|7005d45845be48ae8140d43da96dd17b|0|0|637430504959163367|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=pmMr6SqF27qmrjh1x%2B%2Bjxr8GLikvJUM62zcwN325yDc%3D&reserved=0 (99)
M model/src/ini_parms.Fhttps://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMITgcm%2FMITgcm%2Fpull%2F396%2Ffiles%23diff-977e08a66d018113b62bd72230d9cc2448e55ef980e7112e6c1b6c36d2c3f12e&data=04|01|bron.c.nelson%40nasa.gov|ceb5cf6c84d541ede5dc08d89baac0a1|7005d45845be48ae8140d43da96dd17b|0|0|637430504959173324|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=T5m3Tizr6zP69SvrcAjiahtbiIFSwyQYNMiopFPfLwA%3D&reserved=0 (2)
M model/src/packages_boot.Fhttps://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMITgcm%2FMITgcm%2Fpull%2F396%2Ffiles%23diff-6199f5d884feb0d72ad6a8ad1bda025a1bfcc380e1619659893458cd67c25827&data=04|01|bron.c.nelson%40nasa.gov|ceb5cf6c84d541ede5dc08d89baac0a1|7005d45845be48ae8140d43da96dd17b|0|0|637430504959173324|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=L2EnOeKYKufuykkD00Lisx%2Fs1%2B4Tl1z1J13B1jTbBP0%3D&reserved=0 (2)
M pkg/bbl/bbl_readparms.Fhttps://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMITgcm%2FMITgcm%2Fpull%2F396%2Ffiles%23diff-b19ee2e66c67cf935f4f97d2d78eca825c1b8866c5583fe04a86dbe63b261e32&data=04|01|bron.c.nelson%40nasa.gov|ceb5cf6c84d541ede5dc08d89baac0a1|7005d45845be48ae8140d43da96dd17b|0|0|637430504959183282|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=T5gVtXPNFlMmv9iPIsjd3u5nvW2Fmmsg%2F%2Bd8R7Ya4Xo%3D&reserved=0 (2)
M pkg/cal/cal_readparms.Fhttps://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMITgcm%2FMITgcm%2Fpull%2F396%2Ffiles%23diff-0b99ed7b36bae0c0bdc95c11e4787685983d43e6cf145812c31978c94ce9ede1&data=04|01|bron.c.nelson%40nasa.gov|ceb5cf6c84d541ede5dc08d89baac0a1|7005d45845be48ae8140d43da96dd17b|0|0|637430504959193237|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=lFylWooLJi3g6%2FtvlZdFFKOWeqK85Q5o8Argt5xD%2Fa0%3D&reserved=0 (2)
M pkg/diagnostics/diagnostics_readparms.Fhttps://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMITgcm%2FMITgcm%2Fpull%2F396%2Ffiles%23diff-930718360b6e7ff0b9eefafc9dc2ab3f8ba90807366ce68d0208d08b3b08a2c9&data=04|01|bron.c.nelson%40nasa.gov|ceb5cf6c84d541ede5dc08d89baac0a1|7005d45845be48ae8140d43da96dd17b|0|0|637430504959193237|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=k5HHOlBonQwxmluLouZBfCzJBPr5Lk6MT5ANHwCvct4%3D&reserved=0 (2)
M pkg/exch2/w2_eeboot.Fhttps://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMITgcm%2FMITgcm%2Fpull%2F396%2Ffiles%23diff-ae13e3293fb2ac61a43ff62448177dbff06123f577717c47d962be59716ca204&data=04|01|bron.c.nelson%40nasa.gov|ceb5cf6c84d541ede5dc08d89baac0a1|7005d45845be48ae8140d43da96dd17b|0|0|637430504959203192|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=aOmgbBGQHa2edp7CGZdD2VDIuPKdIbNBkVjdLlk90RM%3D&reserved=0 (2)
M pkg/exch2/w2_readparms.Fhttps://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMITgcm%2FMITgcm%2Fpull%2F396%2Ffiles%23diff-99de1b24dc4fe5f4acc81a164bb4a957b18bd5a947381a8fb2d9ef599b440b3a&data=04|01|bron.c.nelson%40nasa.gov|ceb5cf6c84d541ede5dc08d89baac0a1|7005d45845be48ae8140d43da96dd17b|0|0|637430504959203192|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=0v8LTcvfin2thJH1tc7KFm%2FxQwDkt%2BfRknQnQjZNqNs%3D&reserved=0 (2)
M pkg/exf/exf_interp_read.Fhttps://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMITgcm%2FMITgcm%2Fpull%2F396%2Ffiles%23diff-6a262c2273a13a2f3e433e4f9c544c2af4c76925aa1241e7727ec894a896a106&data=04|01|bron.c.nelson%40nasa.gov|ceb5cf6c84d541ede5dc08d89baac0a1|7005d45845be48ae8140d43da96dd17b|0|0|637430504959213144|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=L2Kj892YpgqyCH3utMXaJsyGXiCwFeDJjhZ%2FIK49WCY%3D&reserved=0 (2)
M pkg/exf/exf_readparms.Fhttps://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMITgcm%2FMITgcm%2Fpull%2F396%2Ffiles%23diff-f42875521a1b4309eaab491785303df68883fba5efa5b7e903688305599b98fb&data=04|01|bron.c.nelson%40nasa.gov|ceb5cf6c84d541ede5dc08d89baac0a1|7005d45845be48ae8140d43da96dd17b|0|0|637430504959213144|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=axkq0VnjeqjkYxa5mO%2FhasZ1I6P75LsDHxq0RvLYl%2FE%3D&reserved=0 (2)
M pkg/kpp/kpp_readparms.Fhttps://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMITgcm%2FMITgcm%2Fpull%2F396%2Ffiles%23diff-d923a2ede2f63fd32b346702d84cd9e81f279317f0ea2bd27cefc7a69b035190&data=04|01|bron.c.nelson%40nasa.gov|ceb5cf6c84d541ede5dc08d89baac0a1|7005d45845be48ae8140d43da96dd17b|0|0|637430504959223105|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=vVcY9%2FI3FAjP8xRV9xhETz%2Fwz2RD0DJlC3rq1UX6EMQ%3D&reserved=0 (2)
M pkg/mdsio/mdsio_facef_read.Fhttps://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMITgcm%2FMITgcm%2Fpull%2F396%2Ffiles%23diff-4e09a8ce855c5c0f2a8ab0551ca030ffafad704d95c7b70e8dfc31a36f6cecc2&data=04|01|bron.c.nelson%40nasa.gov|ceb5cf6c84d541ede5dc08d89baac0a1|7005d45845be48ae8140d43da96dd17b|0|0|637430504959223105|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=5zoSKtxcIl%2BUmeDrJrP2BENnuCBBN4cwCHrU%2FtkHEOg%3D&reserved=0 (146)
M pkg/mdsio/mdsio_read_field.Fhttps://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMITgcm%2FMITgcm%2Fpull%2F396%2Ffiles%23diff-d8e5e606b4b9565454fbcc72bf963050a1980f793d07724c073258c855a9fb17&data=04|01|bron.c.nelson%40nasa.gov|ceb5cf6c84d541ede5dc08d89baac0a1|7005d45845be48ae8140d43da96dd17b|0|0|637430504959233069|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=9nwcANXgBaWXbPXEO73ZfOTFDH%2FyghWFep1EJ0fxaA4%3D&reserved=0 (6)
M pkg/mdsio/mdsio_read_meta.Fhttps://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMITgcm%2FMITgcm%2Fpull%2F396%2Ffiles%23diff-48598b8beb59f810d9185ff9bc3a831b5b7a354e8d7fd6d069f534f20be42385&data=04|01|bron.c.nelson%40nasa.gov|ceb5cf6c84d541ede5dc08d89baac0a1|7005d45845be48ae8140d43da96dd17b|0|0|637430504959233069|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=Kw39KdJ%2BDOb2uG%2FveUVsZHndLAF%2FaeH4EYW32RplqdE%3D&reserved=0 (3)
M pkg/salt_plume/salt_plume_readparms.Fhttps://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMITgcm%2FMITgcm%2Fpull%2F396%2Ffiles%23diff-167614ff7104dd4d06ef3c7da72a0a1a538de5bb1cb4a927bc996f47f4d785c8&data=04|01|bron.c.nelson%40nasa.gov|ceb5cf6c84d541ede5dc08d89baac0a1|7005d45845be48ae8140d43da96dd17b|0|0|637430504959243012|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=IA7lpRuV0BbdwRVmmxU1d3xAf7LKsgzdGf%2FAu73chHg%3D&reserved=0 (2)
M pkg/seaice/seaice_readparms.Fhttps://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMITgcm%2FMITgcm%2Fpull%2F396%2Ffiles%23diff-412afb21498b152e151475fed1582304c02fae146a592d24f7ea2a8b38dcf9f6&data=04|01|bron.c.nelson%40nasa.gov|ceb5cf6c84d541ede5dc08d89baac0a1|7005d45845be48ae8140d43da96dd17b|0|0|637430504959243012|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=l8KQMWveg6idzxR0Zxf8JI%2B4wj3l%2F36SBQ3Fi9onzL4%3D&reserved=0 (2)

Patch Links:

https://github.com/MITgcm/MITgcm/pull/396.patchhttps://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMITgcm%2FMITgcm%2Fpull%2F396.patch&data=04|01|bron.c.nelson%40nasa.gov|ceb5cf6c84d541ede5dc08d89baac0a1|7005d45845be48ae8140d43da96dd17b|0|0|637430504959252984|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=%2F5dUpef5VxZog7hkC419Hd%2FOlxMDooZS0eA4n6BqdDk%3D&reserved=0
https://github.com/MITgcm/MITgcm/pull/396.diffhttps://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMITgcm%2FMITgcm%2Fpull%2F396.diff&data=04|01|bron.c.nelson%40nasa.gov|ceb5cf6c84d541ede5dc08d89baac0a1|7005d45845be48ae8140d43da96dd17b|0|0|637430504959252984|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=%2BgCDyg3H6ubxsQVdiv%2FFLg0vRxIAGLTRQjDHv1%2BYnNA%3D&reserved=0
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHubhttps://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMITgcm%2FMITgcm%2Fpull%2F396&data=04|01|bron.c.nelson%40nasa.gov|ceb5cf6c84d541ede5dc08d89baac0a1|7005d45845be48ae8140d43da96dd17b|0|0|637430504959262936|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=AiwUMg%2BhdN2R15CfgfN01NmqONGh7Ty1IfBT%2Fdj2kGk%3D&reserved=0, or unsubscribehttps://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FABH7CSLAIYAR3ZFUAPNCQKLSTVHKLANCNFSM4URCYCZA&data=04|01|bron.c.nelson%40nasa.gov|ceb5cf6c84d541ede5dc08d89baac0a1|7005d45845be48ae8140d43da96dd17b|0|0|637430504959511843|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=UF00zIEIpc3I%2BRBChXaHKbeGKT5%2FuVk4Ybx6gXe0lWc%3D&reserved=0.

I ran the llc_2160 case under the IOT tool.  Setting #define SINGLE_DISK_IO definitely improves things by eliminating STDOUT and STDERR files from all but one rank.  This setting does NOT cover all the poor Lustre interactions covered by this PR.  I'll run the case with the suggested mods and measure the startup time again.

I am suggesting to close this PR, since most (if not all) CI tests failed and have not seen any progress in fixing these tests for more than 2 months.
As outline in section <IP_ADDRESS> of the documentation, there is very little incentive to comment or suggest improvement on a PR that does not pass CI tests, and the recommended  approach (see manual section 5) to discuss ways of improvement is to open an issue.
@dkokron I suggest that you don't delete this branch on your own fork: As I understand, the code changes here could be useful
for benchmark of one (or few) set-up on one specific machine with one specific file-system.


Random Review questions:

This is just a list of questions I would tend to put in a code review. Because they are not necessarily issues (I could be misunderstanding something) I am putting them all together here, but in separate comments. If any of them rise to level of an individual issue, we use the "Reference in new issue" feature to create a new issue for it.

Are the default values for FeatureNameLineEdit and TimePointLineEdit actually good generic default values, or are theu specific to your particular training data?
https://github.com/mturja-vf-ic-bd/SlicerDeepLearningUI/blob/16810de8b7da5da2a08f41c548e79603c118241d/DeepLearner/DeepLearner.py#L83

Is the choice to connect to signal currentNodeChanged(vtkMRMLNode*) for TrainDirLineEdit, maxEpochLineEdit, batchSizeLineEdit, learningRateLineEdit correct? I don't QLineEdit has the signal. Would textChanged be the better signal? QLineEdit signals

In initializeParameterNode, it seems you are changing the return type (based on the commented out code) from None to int. In python, you have a function you want to do nothing, the pass keyword is typically used.
E.g.
def initializeParameterNode(self):
    pass

https://github.com/mturja-vf-ic-bd/SlicerDeepLearningUI/blob/16810de8b7da5da2a08f41c548e79603c118241d/DeepLearner/DeepLearner.py#L157-L171

These are dataset specific default values.

Do you suggest changing them?

If this is meant to be a general purpose deep learning module, then yes. I could reasonably see them being blank by default and need to be set by the user.

The docstring for DeepLearnerLogic.process needs to describe the parameters for args if anyone is expected to be able to use it.
It would probably be even better if it took separate (documented) keyword arguments rather than a dictionary.

Changed the argument of the process function which now takes each argument individually instead of a dictionary. Also added proper documentation for these arguments.

I think 'TimePointLineEdit' is generic. The FeatureNameLineEdit is somewhat generic in that the user might have multiple features for the same subject and may want to train on different features separately.

Is the choice to connect to signal currentNodeChanged(vtkMRMLNode*) for TrainDirLineEdit, maxEpochLineEdit, batchSizeLineEdit, learningRateLineEdit correct? I don't QLineEdit has the signal. Would textChanged be the better signal? QLineEdit signals

Thanks for pointing that out. I agree.

Re: args to process
Looks good. My only couple comments:

it seems that the gpus argument should probably be a boolean and not an int, and possibly use_gpu would be a more apt name.
From first glance and reading its documentation, I have no clue what the monitor argument does, so maybe that documentation could be fleshed out more (or add a url to something if appropriate)

think 'TimePointLineEdit' is generic. The FeatureNameLineEdit ...

I wasn't questioning the line edits, just their default values.

A couple nitpick thing you don't need to change, but could be nice.
The Maximum Epoch, Learning Rate, and Batch Size are all numbers, so QSpinBox, QDoubleSpinBox, and ctkSliderWidget all seem more appropriate than a line edit for taking input.

Re: args to process
Looks good. My only couple comments:

it seems that the gpus argument should probably be a boolean and not an int, and possibly use_gpu would be a more apt name.
From first glance and reading its documentation, I have no clue what to put for the monitor argument, so maybe that documentation could be fleshed out more (or add a url to something if appropriate)

Fixed these issues.

A couple nitpick thing you don't need to change, but could be nice.
The Maximum Epoch, Learning Rate, and Batch Size are all numbers, so QSpinBox, QDoubleSpinBox, and ctkSliderWidget all seem more appropriate than a line edit for taking input.

Fixed these issues.

RE: monitor argument
That looks good, thanks. I think validatin/precision might be a typo though

I got warnings when running the module.
PythonQt: QObject::connect() signal 'textChanged(str)' does not exist on QLineEdit
PythonQt: QObject::connect() signal 'textChanged(str)' does not exist on QSpinBox
PythonQt: QObject::connect() signal 'textChanged(str)' does not exist on QSpinBox
PythonQt: QObject::connect() signal 'textChanged(str)' does not exist on QDoubleSpinBox

Probably from
https://github.com/mturja-vf-ic-bd/SlicerDeepLearningUI/blob/e45948d5d00428fee03827b09f19513a4f727da2/DeepLearner/DeepLearner.py#L96-L100
For the QLineEdit which does have a textChanged signal, you can connect like this:
self.ui.TrainDirLineEdit.textChanged.connect(self.updateParameterNodeFromGUI)

Similarly for the spinboxes you can do something like
self.ui.epochSpinBox.valueChanged.connect(self.updateParameterNodeFromGUI)

If you run start trainer again after running, it does not reset the progress bar back down to 0.

Fixed those issues.

Closing as issues have been addressed.


Provide working example for External Volumes

Please provide a working example (tutorial/deep dive) for External Volumes
This may be integrated into the DC/OS docs, but it should at least be a part of the Marathon documentation.
An example of a deep dive can be found here: https://github.com/dcos/dcos-docs/pull/66
Note: this should be done by eod 04/15

Documentation is here: https://mesosphere.github.io/marathon/docs/external-volumes.html


Added KeyExchange and HostKeys for SshOption

This PR added 2 more SshOptions. They are used in connection/authentication stage.

Thanks!


DECRIPTION : EXPONENTIAL MOVING AVERAGE (50)

DECRIPTION : EXPONENTIAL MOVING AVERAGE (50)
CONDITION/PARAMETER : GIVE A BUY SIGNAL WHEN THE ASSET PRICE CLOSED ABOVE THE EMA50 VALUE AND VICE VERSA GIVE A SELL SIGNAL WHEN THE ASSET PRICE CLOSED BELOW OR LOWER THAN EMA50 VALUE

LINK FOR FURTHER DETAILED EXPLANATION OF EXPONENTIAL MOVING AVERAGE:
https://www.investopedia.com/terms/e/ema.asp
Originally posted by @Cal231995 in https://github.com/ta-oliver/infertrade/issues/141#issuecomment-874682965

@bi-kash you can found the mathematical formula for ema on this one https://www.investopedia.com/terms/e/ema.asp
for further understanding of the indicator.
@fhashim we can collab here for the creation of pdf for this rule.

@Cal231995 - we need the rules to have specific outputs in terms of portfolio allocation.
So for example the "buy" signal could take a 100% position.
However as 100% might be too big, we could consider having the investment size as a parameter "max_investment" ranging from 0.0 to 1.0.
Does a sell signal mean go short (negative allocations) or is it saying sell any holdings?
So one rule could be:
if price > ema_50_avg:
position = max_investment
else:
position = 0.0

However as 100% might be too big, we could consider having the investment size as a parameter "max_investment" ranging from 0.0 to 1.0. - yes sir agreed on this one.
Does a sell signal mean go short (negative allocations) or is it saying sell any holdings? -  yes sir, a sell signal is also equal to go shorting, means selling your current long position and going on to short position.
So one rule could be:
if price > ema_50_avg:
position = max_investment
else:
position = 0.0
A different rule (which takes shorts) would be:
if price > ema_50_avg:
position = max_investment
else:
position = -max_investment
yes sir, both rules are correct. the 2nd one just have a short option, where other platform/brokers doesn't facilitate shorting.
I think we can test the first one first and see if will need to improve it with the shorting option.

The shorting option (2nd rule) will provide more returns I think.
A different rule (which takes shorts) would be:
if price > ema_50_avg:
position = max_investment
else:
position = -max_investment

I think we can test the first one first and see if will need to improve it with the shorting option.

So we can go for the second one and then use the restriction decorator to create the first rule - it wouldn't need to be a separate rule.
There would be two parameters: max_investment (default 0.5) and exponential_window (default 50).

yes sir. that would be the ideal approach

Hi Sir @ta-oliver please see attached file for proposed workflow process of using tech indicator as a signal to find predictability.
for your comments and approval.
Inferstat Improvements.xlsx

ALSO I'VE TESTED THIS EMA(50) RULE MANUALLY AND PRODUCE RESULTS DEPENDING ON ALLOCATIONS THAT WERE USED.
INITIAL RESULTS SHOWED THAT BIGGER ALLOCATION RESULTS TO BIGGER RETURNS.
SEE DIFFERENT DATAS BELOW THANKS.


Stryker for nodeunit + jscoverage

I have a tiny side project that is so simple it gets away with nodeunit and jscoverage for testing. The project uses grunt to fire off the tests. See https://github.com/bkimminich/z85-cli
It would be nice to have styker support it, but I'm not sure if the JS community considers these as dead horses...? :horse:

I think we should support nodeunit. I think adding an other node testrunner should be rather simple. It's both a test runner and a test framework correct?
As for jscoverage: we're actually working on the next major version of the stryker-api (should be 0.3). We will move the responsibility for code coverage instrumentation to Stryker itself, as well as the responsibility for reporting on the code coverage for node based test runners. You can see our plans in https://github.com/stryker-mutator/stryker-api/issues/4.

I haven't used jscoverage myself, why would you use it over something like Istanbul?

Are you still interested in nodeunit support? If not, i want to close this issue for now. We haven't had anyone else that's interested in using nodeunit.


add more BlockBatches utils

thinks like:
merge(other): merges other blockbatch in itself
mirrorX(): mirrors the batch on the x pos
mirrorY(): mirrors the batch on the y pos
mirrorZ(): mirrors the batch on the z pos
rotate(clockwise, degrees) rotates the batch
would be cool to have but i dont know how hard it is to implement

Improvements for the batch API have been mentioned but it is currently not a priority. May also be better to finish the light engine before.


Adding a response media type

"mediaType" has been renamed to "requestMediaType"
added an additional field "responseMediaType"

@rcchen for SA

fixes https://github.com/palantir/typescript-service-generator/issues


Rapidly skipping through playlist tracks can throw console error

Rapid-fire skips can lead to a console error: Uncaught (in promise) DOMException: The play() request was interrupted by a call to pause().
While this error doesn't (yet) appear to have any particular negative consequences, we should try to avoid throwing it.
This answer from Stack Overflow may help us think about how to solve the problem.

There's not a clear perfect solution for this one. We have a couple of partial solutions:

In supporting browsers, wait on the Promise from the play and pause methods to fire another play or pause.
Only play or pause if we aren't already in that state.
The problem is (I tested it), there's another similar error which will crop up even if we did sequence the method calls: Uncaught (in promise) DOMException: The play() request was interrupted by a new load request.

This one's trickier - the load request is because we assigned the src attribute on our audio element, and we don't have a clear way to wait on that. We could try to obfuscate it, but since all our functionality already works, and this error only surfaces for extremely fast song navigation, it would be best to let the errors surface in the console, in case one of them is actually important.


External-secret error AccessDeniedException for cross AWS Account secret manager

Describe the bug
Trying to fetch the secret in AWS Account 1 (in which AWS EKS and ESO are installed ) from AWS Account 2 (in which the secret resists) but I faced this error:
Warning  UpdateFailed  1s (x12 over 12s)  external-secrets  AccessDeniedException: User: arn:aws:sts::AWSACCOUNTID1:assumed-role/EKSSecretsReaderRole/external-secrets-provider-aws is not authorized to perform: secretsmanager:GetSecretValue on resource: appsecret/test/new-test because no identity-based policy allows the secretsmanager:GetSecretValue action
status code: 400,`
Note: I have to mention that I can perfectly get any secret from AWS Account 1 but I can not get a secret from AWS Account 2 (cross AWS account)!!
What I did
Steps to reproduce the behavior:

I Installed AWS EKS, and ESO (installed in external-secrets namespace)
Create AWS policy and Role in AWS Account 1
Create a secret in secret manager in AWS Account 2 with a specific policy
Give access to KMS on AWS Account 2 to Role of AWS Account 1
Create and service account ( service account name external-secrets ) in the external secret  namespace with annotation of role in AWS Account1
Create a cluster secret store and give access to the service account of external-secret.
Both secrets exist in both AWS Accounts in the us-east-2 region

Role Trust relationships:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Federated": "arn:aws:iam::AWSACCOUNT1ID:oidc-provider/oidc.eks.us-east-2.amazonaws.com/id/11111112222333333"
},
"Action": "sts:AssumeRoleWithWebIdentity",
"Condition": {
"StringEquals": {
"oidc.eks.us-east-2.amazonaws.com/id/11111112222333333:aud": "sts.amazonaws.com",
"oidc.eks.us-east-2.amazonaws.com/id/11111112222333333:sub": "system:serviceaccount:external-secrets:external-secrets"
}
}
}
]
}

Polic has attached to the role:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"secretsmanager:GetResourcePolicy",
"secretsmanager:GetSecretValue",
"secretsmanager:DescribeSecret",
"secretsmanager:ListSecretVersionIds"
],
"Resource": [
"arn:aws:secretsmanager:us-east-2:AWSACCOUNT1ID:secret:appsecret/dev/",
"arn:aws:secretsmanager:us-east-2:AWSACCOUNT1ID:secret:appsecret/stage/",
"arn:aws:secretsmanager:us-east-2:AWSACCOUNT2ID:secret:appsecret/test/*"
]
},
{
"Effect": "Allow",
"Action": "kms:Decrypt",
"Resource": [
"arn:aws:kms:us-east-2:AWSACCOUNT1ID:key/KMSIDINAWSACCOUNT1",
"arn:aws:kms:us-east-2:AWSACCOUNT2ID:key/KMSIDINAWSACCOUNT2"
]
}
]
}

Policy has attached to secret on AWS Account 2:
{
"Version" : "2012-10-17",
"Statement" : [ {
"Effect" : "Allow",
"Principal" : {
"AWS" :  "arn:aws:iam::AWSACCOUNT1ID:role/EKSSecretsReaderRole"
},
"Action" : "secretsmanager:",
"Resource" : ""
} ]
}

Added policy to KMS in AWS Account 2:
{
"Sid": "AllowUseOfTheKeyFromAWSACCOUNT1IDEKSSecretsReaderRole",
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws:iam::AWSACCOUNT1ID:role/EKSSecretsReaderRole"
]
},
"Action": [
"kms:Decrypt",
"kms:DescribeKey"
],
"Resource": "*"
}
Expected behavior
I expect that when trying to apply my external secret object to fetch my secret from the cross AWS Account and create a secret from that object's external secret.
Screenshots
When I am trying to apply an external secret object it shows SecretSyncedError with this error:
Events:
Type     Reason        Age                From              Message

Warning  UpdateFailed  1s (x12 over 12s)  external-secrets  AccessDeniedException: User: arn:aws:sts::AWSACCOUNTID1:assumed-role/EKSSecretsReaderRole/external-secrets-provider-aws is not authorized to perform: secretsmanager:GetSecretValue on resource: appsecret/test/new-test because no identity-based policy allows the secretsmanager:GetSecretValue action
status code: 400,
Additional context
EKS version: 1.26
ESO helm chart version: v0.8.3
In the end, I have to say again I get any secret from the same AWS account that EKS has been installed but I can not get a secret from a cross AWS Account!!

Hey, can you share your ExternalSecret and SecretStore resources?
Typically i would configure the SecretStore to authenticate with IRSA using a role in AWS_ACCOUNT_1. That role only allows sts:assumeRole permissions, so that ESO is able to assume a role in AWS_ACCOUNT_2.
That role in AWS_ACCOUNT_2 has all the permissions needed to read secrets + decrypt using KMS.

Hi Moolen, Thanks for your answer, sure
here is my external secret config:
apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
annotations:
name: new-app-externalsecret
namespace: external-secrets
spec:
dataFrom:

extract:
conversionStrategy: Default
decodingStrategy: None
key: appsecret/test/new-test
refreshInterval: 1m
secretStoreRef:
kind: ClusterSecretStore
name: development-css
target:
creationPolicy: Owner
deletionPolicy: Retain
name: new-app-secret

and this external-secret object is going to use clustersecretstore which is:
apiVersion: external-secrets.io/v1beta1
kind: ClusterSecretStore
metadata:
name: development-css
spec:
provider:
aws:
service: SecretsManager
region: us-east-2
auth:
jwt:
serviceAccountRef:
name: external-secrets
namespace: external-secrets

and this clustersecret is going to use service account in external-secrets namespace:
apiVersion: v1
kind: ServiceAccount
metadata:
annotations:
eks.amazonaws.com/role-arn: arn:aws:iam::AWSACCOUNT1ID:role/EKSSecretsReaderRole
labels:
app.kubernetes.io/instance: external-secrets
name: external-secrets
namespace: external-secrets

Hey Moolen, I just want to say thank you for your tips that helped me a lot, I fixed the problem by doing the below changes:

I added allows the role to sts:assumeRole permissions in Account1 to assume the role of account2.
Added this line role: arn:aws:iam::AWSACCOUNTID2:role/AllowReadSecret to the ClusterSecretStore object.

by changing the above config my External-secrets is able to create a secret.
Again Thank you so much. :)

Hey, glad to hear it worked!
I think the setup you described above should work, too. I think you just need to specify the key: appsecret/test/new-test  as a valid ARN. Otherwise ESO tries to fetch the secret appsecret/test/new-test from ACCOUNTID1.

ARN is arn:${Partition}:secretsmanager:${Region}:${Account}:secret:${SecretId}, which will not just contain the name of the secret, but it also appends a dash followed by a string of characters that are unique to that secret.
The following CLI command will provide the complete ARN of the secret considering that appsecret/test/new-test is the name of your secret:
aws secretsmanager describe-secret --secret-id appsecret/test/new-test

You would also find the complete ARN of the secret in the Secrets Manager console -> by selecting the name of the secret -> under "Secret details" section.
Taken from here :sweat_smile:


qrcode should be qr_data

Tried to generate stock labels by using a template I found that qrcode should be qr_data in docs/report/labels.md I guess

Thanks, fix incoming!


Update AddField.cs

Hi @etiennebailly, I'm your friendly neighborhood Microsoft Pull Request Bot (You can call me MSBOT). Thanks for your contribution!

This seems like a small (but important) contribution, so no Contribution License Agreement is required at this point. Real humans will now evaluate your PR.

TTYL, MSBOT;

Updated help.
Original operations on wrong files :https://github.com/OfficeDev/PnP/pull/967

Hi Etienne! Thank you for your contribution!. I will merge.


Bugfix: joint_state command output & documentation

Small bugfix on the joint_state command output & documentation.

Hi,
Good catch, thanks!
I wrote this node mostly as a tutorial and should have tested it a bit ;)


docs: Improve UX by Extending Clickable Area for Switch Component

Close #2874
Issue Details
As demonstrated in the SwitchDemo example, a user cannot toggle the switch by clicking on the whitespace between the Switch and its Label. This specific behavior contrasts with user expectations set by similar components in other libraries, such as Radix UI, where the clickable area extends to the surrounding whitespace, allowing for a more forgiving click target.
What I did
By removing space-x-2, which prevented toggling, and adding padding to the Label, usability is enhanced by aligning with common user expectations and improving the interaction experience.
Before:
https://www.loom.com/share/4bcb04b031c54f50b15c306da3fe600e?sid=6e9c9cce-3bc3-461a-8479-d76faf3f8b09
After:
https://www.loom.com/share/da928675828d42bf90a373bf34bbf66a?sid=08a12dab-a3fe-4302-b301-e495a36b9e41
Thank you for considering this enhancement. I look forward to your feedback.

I think you can achieve the same using the label as a wrapper
original
import { Label } from "@/components/ui/label"
import { Switch } from "@/components/ui/switch"

export function SwitchDemo() {
  return (

      <Switch id="airplane-mode" />
      Airplane Mode

  )
}

updated
import { Label } from "@/components/ui/label"
import { Switch } from "@/components/ui/switch"

export function SwitchDemo() {
  return (

        Airplane Mode
        <Switch />

  )
}

https://www.w3.org/WAI/tutorials/forms/labels/#associating-labels-implicitly


How to use dep

Workflow:

Ran this from a location where main.go is present: dep init

Committed the Gopkg.toml and Gopkg.lock (not the vendor directory to version control)

In another directory, updated the project and ran dep ensure to make sure that the dependencies are maintained/updated.

Maybe I am missing something basic here, any help will be appreciated. EDIT: This is what will be the perfect way to get up and running immediately with dep.

 Error message:

go build main.go
# vendor/github.com/cloudflare/cfssl/scan
vendor/github.com/cloudflare/cfssl/scan/tls_handshake.go:53:71: undefined: "crypto/tls".CipherSuites
vendor/github.com/cloudflare/cfssl/scan/tls_handshake.go:64:74: undefined: "crypto/tls".Curves
vendor/github.com/cloudflare/cfssl/scan/tls_handshake.go:68:101: undefined: "crypto/tls".SignatureAndHash
vendor/github.com/cloudflare/cfssl/scan/tls_handshake.go:87:13: undefined: "crypto/tls".AllSignatureAndHashAlgorithms
vendor/github.com/cloudflare/cfssl/scan/tls_handshake.go:91:86: conn.SayHello undefined (type *"crypto/tls".Conn has no field or method SayHello)
vendor/github.com/cloudflare/cfssl/scan/tls_handshake.go:100:77: undefined: "crypto/tls".Versions
vendor/github.com/cloudflare/cfssl/scan/tls_handshake.go:106:5: undefined: "crypto/tls".CipherSuites
vendor/github.com/cloudflare/cfssl/scan/tls_handshake.go:121:35: undefined: "crypto/tls".CipherSuites
vendor/github.com/cloudflare/cfssl/scan/tls_handshake.go:122:24: undefined: "crypto/tls".CipherSuites
vendor/github.com/cloudflare/cfssl/scan/tls_handshake.go:129:32: undefined: "crypto/tls".CipherSuite
vendor/github.com/cloudflare/cfssl/scan/tls_handshake.go:129:32: too many errors

Expectation:

That all the dependency management will happen in the background once I ran dep ensure.
Teams just need a dep ensure to update their state locally and can then issue a build, run, install command.

What version of dep are you using (dep version)?
 dep-linux-amd64  version
dep:
 version     : v0.3.2
 build date  : 2017-10-19
 git hash    : 8ddfc8a
 go version  : go1.9
 go compiler : gc
 platform    : linux/amd64

@krish7919 hi, thanks for opening an issue.
I think the issue is because of difference in the way dependencies are vendored in github.com/cloudflare/cfssl. I see that they have a vendor/ directory at the root of the project, but then there's another vendor directory inside package scan, which is unusual. dep performs static analysis of projects and downloads all the dependencies if the import paths are correct. But in this case, I see "crypto/tls" package, which has the import path format of a standard library package, but the vendored package is different from what's there in the standard library.
Since dep removes any existing vendor directories and tries to download the dependencies itself, "crypto/tls" in scan package's vendor would have been removed by dep and while compiling it fails because the standard library "crypto/tls" has no methods that are used in tls_handshake.go.
I've never seen such setups. Not sure how to fix it. Vendoring in github.com/cloudflare/cfssl should be fixed/improved to fix this issue.

That all the dependency management will happen in the background once I ran dep ensure.
Teams just need a dep ensure to update their state locally and can then issue a build, run, install command.

Your expectations are right, just dep ensure is all that's required.

Just a thought, maybe if you ignore github.com/cloudflare/cfssl/scan, you could make it work. Because I see the code in scan package don't have any other external dependencies, other than the custom vendored dependencies.
Here is a document about how to use ignored in Gopkg.toml https://github.com/golang/dep/blob/master/docs/Gopkg.toml.md#ignored. Give it a try?


Fixthis first

Pull Request (PR) description

This Pull Request (PR) fixes the following issues

Task list

[ ] Added an entry under the Unreleased section of the change log in the CHANGELOG.md.
Entry should say what was changed, and how that affects users (if applicable).
[ ] Resource documentation added/updated in README.md in the resource folder.
[ ] Resource parameter descriptions added/updated in schema.mof
and comment-based help.
[ ] Comment-based help added/updated.
[ ] Localization strings added/updated in all localization files as appropriate.
[ ] Examples appropriately added/updated.
[ ] Unit tests added/updated. See DSC Resource Testing Guidelines.
[ ] Integration tests added/updated (where possible). See DSC Resource Testing Guidelines.
[ ] New/changed code adheres to DSC Resource Style Guidelines and Best Practices.

This change is

Codecov Report

Merging #182 into dev will decrease coverage by 2%.
The diff coverage is 69%.

@@         Coverage Diff         @@
##           dev   #182    +/-   ##
===================================
- Coverage   90%    87%    -3%
===================================
  Files        7      8     +1
  Lines      715    821   +106
===================================
+ Hits       648    722    +74
- Misses      67     99    +32


readdir_r function definition not found

I am trying to build libphonenumber cpp code using visual studio. generate_geocoding_data.cc file includes dirent.h header but in msvc dirent.h is not available.
I follow the all guidelines given in the document

I have the same problem, all the dirent.h version found in internet do not provide readdir_r implementation

@lo-re If you want to build cpp libphonenumber then you can build it without using geocoding library. It does not require dirent.h.

@pnkjvvdy,
Thank you for taking the time to improve libphonenumber!
Yes, it is not possible to compile generate_geocoding_data.cc for Windows as it depends on the readdir_r() function which is not provided by Windows.
This issue is duplicate of #824 and it will be tracked there. So closing this issue.
We'd be happy if you can contribute to PR #1090 which is intended to solve this problem.


Refactor backend to use application factory pattern

The backend is currently quite generically implemented. It would be better to switch to a known pattern, e.g. the application factory pattern.
At the same time it'll make sense to alter the database solution to a true ORM, such as flask-sqlalchemy. Furthermore, switching to application factory pattern should make testing much cleaner with pytest.

lgtm jo


Tailwind @apply notation with multiple classes inline gives semi-colon-expected  scss(css-semicolonexpected) error

Does this issue occur when all extensions are disabled?: Yes

VS Code Version: 1.56.2 (Universal)
OS Version: macOS 11.2

Steps to Reproduce:

Open any tailwind integrated with the SCSS project
use @apply annotation and use multiple tailwind classes in one-row space-separated.

What is happening:
Vscode shows SCSS formatted error though it's correct and works fine, it irritates to see red lines across SCSS file

every class has to be on a new line, then the error (semi-colon-expected  scss(css-semicolonexpected)) goes away
Expected Behaviour:
Should not show error for @apply notations or provide a setting to ignore custom ones

(Experimental duplicate detection)
Thanks for submitting this issue. Please also check if it is already covered by an existing one, like:

[scss] provide hover for scss functions (#86765)

no it is not relevant

even I'm also issue facing the same issue, thanks for reporting this @pranav-js, when is the fix @aeschli ? thanks in advance.

@apply is a css at rule that has been deprecated since.: https://tabatkins.github.io/specs/css-apply-rule/
You are coming from Tailwind which uses @apply with a multiple arguments.
Unfortunately we need to focus on standardized css/scss, so I can't help you here.

@aeschli  this is not the @apply you have pointed to, it's a postcss annotation. please correct me if I'm wrong https://github.com/tailwindlabs/tailwindcss/issues/381#issuecomment-364787287

The point is that we don't have support for postcss syntax, only for standard css.

alright gotcha!

Fixed for May.
@apply is now an unknown at rule, which is ignored (unless you set the linter setting)

@aeschli  that's great.. but do you mean we still need to have custom linter for this? can you link PR please :)

The linking would have to come from an extension that knows postcss.
The built-in css extension is only about css, and will ignore all unknown at-rules unless you configure the setting css.lint.unknownAtRules.

for scss folks
use
"scss.lint.unknownAtRules": "ignore",


Wrong link on abour me page

Going to the about me tab both of the links will lead to tosdr.org/legal

Will be fixed in the next version.


Conditional XAML doesn't work for Attached Properties

Originally Filed here: https://github.com/MicrosoftDocs/windows-uwp/issues/1378
Describe the bug
Conditional XAML doesn't seem to work on Attached Properties.  No mention of this limitation was called out in the docs, thus the original bug above.  This should be expected to work?
Steps to reproduce the bug
Steps to reproduce the behavior:
Create a class library
Add contract6Present:AutomationProperties.HeadingLevel="Level2" to your XAML.
Get this error: XAML Binary Format (XBF) generator reported syntax error '0x09cc' in VS
Another user reported:
                            <Windows10version1809:Grid.BackgroundTransition>
                                <Windows10version1809:BrushTransition />
                            </Windows10version1809:Grid.BackgroundTransition>

Expected behavior
No error, conditional XAML should work.
Screenshots

Version Info

NuGet package version:

Windows 10 version
Saw the problem?

Insider Build (xxxxx)

May 2019 Update (18362)

October 2018 Update (17763)

April 2018 Update (17134)

Fall Creators Update (16299)

Creators Update (15063)

Device form factor
Saw the problem?

Desktop

Mobile

Xbox

Surface Hub

IoT

Additional context

@danzil is this a known issue?

Looks like something we should look at according to @alwu-msft

@michael-hawker do you think there is a need for conditional xaml with WinUI3? It was created to solve the downlevel issue, which seems to be a problem we should fundamentally no longer have with WinUI3.

@stevenbrix assuming everything works in WinUI3 for all OS versions with the exact same behavior, will that still be the case for all OS platforms? I can also see the IsTypePresent and IsPropertyPresent conditionals being useful for other libraries and cases beyond just WinUI, especially if loaded via dependency injection?

assuming everything works in WinUI3 for all OS versions with the exact same behavior, will that still be the case for all OS platforms?

Yes, that is the main motivation for lifting the entire WinUI platform out of the OS :)

I can also see the IsTypePresent and IsPropertyPresent conditionals being useful for other libraries and cases beyond just WinUI, especially if loaded via dependency injection?

Interesting, I hadn't thought of that! Can you explain why they would be useful? It would be nice to have a better understanding of what problems it solves in the WinUI3 world.

Seems to work for me? this builds
<Page
    xmlns:muxcWindows11Present="using:Microsoft.UI.Xaml.Controls?IsApiContractPresent(Windows.Foundation.UniversalApiContract, 14)"
    xmlns:windows11NotPresent="http://schemas.microsoft.com/winfx/2006/xaml/presentation?IsApiContractNotPresent(Windows.Foundation.UniversalApiContract, 14)"
    muxcWindows11Present:BackdropMaterial.ApplyToRootOrPageBackground="True"
    windows11NotPresent:Background="{StaticResource SystemControlChromeMediumLowAcrylicWindowMediumBrush}">

Does not repro with WinAppSDK 1.3.


base bgp template model

Pull Request summary:
Add Cisco BGP Model

This issue was migrated from an old repository: https://github.com/CiscoDevNet/catalystwan/pull/331


support for jinja-sql files

dbt should load in .jinja-sql files so we can have independent language servers for both
resolves #

Description

Checklist

[ ] I have read the contributing guide and understand what's expected of me
[ ] I have signed the CLA
[ ] I have run this code in development and it appears to resolve the stated issue
[ ] This PR includes tests, or tests are not required/relevant for this PR
[ ] I have opened an issue to add/update docs, or docs changes are not required/relevant for this PR
[ ] I have run changie new to create a changelog entry

Prior attempt: https://github.com/dbt-labs/dbt-core/pull/3498
And discussion about exactly which file extension to add support for: https://github.com/dbt-labs/dbt-core/issues/3484
We ran into some thorny errors in unit tests that were more difficult to debug than we had capacity at the time.

interesting i thought it would be an easy add. do you have any prior progress on what could be causing failed unit tests?

It's been a while since that PR, but it was trickier business than we anticipated. If I recall correctly, I think one of the tricks was around .sql.jinja containing a dot (.), and dbt supports model names containing dots (.), so there was internal confusion about how to treat some.model.sql.jinja.
The reason we went for that file extension:

the Jinja maintainers, who previously did not endorse an official jinja file extension—preferring to just include Jinja in .html, .md, .xml, whatever—have since thrown their weight behind .jinja (docs, StackOverflow discussion):

Adding a .jinja extension, like user.html.jinja may make it easier for some IDEs or editor plugins, but is not required.

It's possible that .jinja-sql wouldn't run into the same set of issues

@jtcohen6 the reason I use .jinja-sql is because of this vscode extension](https://marketplace.visualstudio.com/items?itemName=samuelcolvin.jinjahtml). vscode (and I would assume most decent IDEs) has a file association feature. perhaps a better feature would be allowing users to define file extensions within dbt that associates to .sql, thus allowing users with an IDE of their choosing on what file extension is considered a jinja file type.

Got it - yeah it looks like the default file associations for that VSCode extension are the ones recommended:

Jinja SQL
Jinja SQL templates: system name jinja-sql.
Default file associations: .sql.j2, .sql.jinja and .sql.jinja2


The subscribe to challenge API

Details

There is no middleware validator present for the /challenges/subscribe API.
This can cause security issues.
It allows users to send any data to this endpoint.
Without a middleware validator, there is no way to ensure data validity and security.
This can lead to potential vulnerabilities and exploits.
It is important to implement a middleware validator to prevent these security issues.

Hey @RitikJaiswal75  I want to take this issue.


Add multipart content type

This is required for https://github.com/vrchatapi/specification/pull/408 to be merged

That's corrcect, it only changes stuff from the following pr:

This is required for vrchatapi/specification#408 to be merged

Okay, but then the documentation of the specification is wrong.
In the specification you write:
                file:
                  type: string
                  format: binary
                  description: The binary blob of the png file.

Yet in this pr you interpret file as a filename to open and read

Yes, that's how the generators create it, the generators create a PathBuf, which (as I understand it) store a Path to a file on disk

Then the description should read The path to the file to be uploaded instead.

The issue with this is that it depends on the generator :)
The C# generator takes in a byte stream

Also using a blocking file read in an async context is not ideal either in this scenario (though I can totally understand that choice)

Honestly the choice was because I don't know almost anything about rust async, I didnt realise that the file reading was sync, I can see if I can turn it into async in a bit

I can see if I can turn it into async in a bit

With the current dependencies std it's imo not possible.
We'll have to pull in some helper crate(s). Something like async-std or tokio (though I think the first choice is more versatile for consumers)

Ah
Well realistically the images won't be too big so do we think that's worth it?
I feel like it might be fine like this

Oh also you use .unwrap(), which is 100% off-limits for us as a crate.

Yeah that's fair lol

Wait, now that I'm thinking about it again, couldn't we just patch the sdk and have the user supply s byte stream and mime type?

Writing a regex replace in regex101.com for that is no problem, but I can't get the regex to actually work.

honestly, throw the regex in chatgpt, it's great at regexes lol

Only thing left is to test this again and then to merge (if you have perms, feel free to merge yourself. If not, I'll merge it, when you said, that it works)

let mut buffer = Vec::new();
let a = File::open("./image.png").unwrap().read_to_end(&mut buffer);
let output = vrchatapi::apis::files_api::upload_icon(&config, buffer, "image.png", "image/png")
    .await
    .unwrap();

this works great, LGTM


Increase simultaneous requests

PR Checklist

[x] Brief description of changes
[x] Links to any relevant issues
[ ] Required status checks are passing
[x] User cases if changes impact the user's experience
[ ] @mention a maintainer to request a review

Hello, I am an intern at Google investigating ways in which to get optimal performance out of medical image viewers that integrate with the Google Healthcare API. One major optimization I've found is increasing the number of simultaneous requests made when fetching a series of DICOM instances/frames. So this PR adds a configuration to cornerstoneTools.stackPrefetch to increase the number of simultaneous http requests.
With the introduction of HTTP/2, there is no longer a limit of 6 simultaneous requests to a specific origin. Instead, one connection is made to a given origin and a hypothetically infinite number of requests can be made through that one connection (although browsers such as chrome do eventually limit these connections which appears to be around 100 requests).  Increasing the number of simultaneous http requests higher than 6 yields major performance improvements as images load much faster.
Currently, a library used in Ohif react-cornerstone-viewport sets the cornerstoneTools maxSimultaneousRequests to 6, overriding any value that we set ourselves. However, I have opened a pull request to remove this configuration which would allow viewers to set these values to whatever they like. Thus, if that pull request gets merged, then we can set the maxSimultaneousRequests to whatever value we like, and I'll add a commit to update to the latest version of react-cornerstone-viewport.
I did some performance tests comparing the load times of different values of concurrent requests w/ Ohif, when loading a study with 619 instances in it, results below:

Max Simultaneous Requests
Time to Load all Instances

6
25.88s

10
17.21s

20
9.92s

50
9.59s

75
10.19s

It appears that after 20 max simultaneous requests, the added benefits become negligible. So in this PR I have set the maxSimultaneousRequests value to 20. As can be seen there is a very large decrease in load times for the 619 DICOM instances simply by increasing the number of simultaneous http requests, allowing users to view the instances much quicker and with less noticeable lag.
Relevant issues
https://github.com/OHIF/Viewers/issues/820
If anyone would like to test this change before the react-cornerstone-viewport PR gets merged, you can use my forked version of the library which won't override the maxSimultaneousRequests.

This all seems very reasonable. Thanks for laying out your case and for taking the time to draft a PR. I'll merge these changes and make sure they're duplicated in our beta branch.

Thanks @dannyrb! One thing I wanted to change before marking this PR as ready for review was update the package.json in extensions/cornerstone to use the latest version of react-cornerstone-viewport once my PR in that library got merged, as this change currently won't be beneficial unless using the latest react-cornerstone-viewport. If you'd like, I could create another PR to update the package.json to use version 4.0.2?

👋 @Alex979, that would be great! A PR that:

Bumps the minimum version for react-cornerstone-viewport
Includes an updated yarn.lock

Would be great. Thanks again ^_^

Thanks for the PR @Alex979 and the nice explanation. This is something that Egor (@pavertomato) also brought up when integrating OHIF with the Google Cloud Healthcare API. I have no problem removing the default and letting people set this themselves at the app level. The tricky thing is that when you have a large number of open requests, depending on the client's connection, the archive and server performance, the latency for each image can increase significantly.
Testing needs to take into account the behaviour of the user rather than just total time to load all instances. One thing that I know @pieper and @fedorov want to test for their work with the [NCI Imaging Data Commons](https://imagingdatacommons.github.io/, which uses a proxy in front of the Google Cloud Healthcare API) is the perceived performance for a user loading a study and then quickly navigating to various locations in a stack, which is typically what we see end users doing. Currently, when the user navigates, we reset the stack prefetch queue to fetch around the image. I'm not sure how the perceived performance is impacted by changes to the maximum simultaneous open requests.


TableStorage returns enparseable etag for Insert operation

Which service(blob, file, queue, table) does this issue concern?
Table
Which version of the Azurite was used?
3.9.0-table-alpha.1
Where do you get Azurite? (npm, DockerHub, NuGet, Visual Studio Code Extension)
NPM
What's the Node.js version?
v14.15.4
What problem was encountered?
Insert entity operation fails when using Azure Storage java library.
IllegalArgumentException is thrown from TableResult.parseETagForTimestamp(String etag)
Debugger indicates that etag value returned by Azurite was "0x205B6F86DEB6480".
Steps to reproduce the issue?
Fails every time for me whenever I add an entity to a table.
I use com.microsoft.azure:azure-storage:8.6.5 library - works fine with Azure Table Storage in the cloud.
Have you found a mitigation/solution?
Nope

@mstrejczek
Currently the Etag generated from Azurite is a string that only matches etag format, it doesn't contain timestamp.
see code https://github.com/Azure/Azurite/blob/aa6cba7904e0c6e147bf1f932981776a09d7d059/src/common/utils/utils.ts#L50
We welcome contribution.
It would be great if you could help to fix the generate etag function!

I've just checked how etag returned by Azure Table Storage looks like and it is something like
W/"datetime'2021-02-01T10%3A58%3A01.2219993Z'"
Basically a constant
W/"datetime'
followed by ISO8601 datetime and then followed by another constant:
"'
I'll try to put together a PR when I have some time.

This ticket can be reproduced with this test app: https://github.com/mstrejczek/azurite-table-test

@mstrejczek
Thanks for the reply!
It would be great if you can raise a PR to fix it.
Please note, as the currently newEtag() if also used by Blob storage in Azurite, would you please write a new function to create etag for table request, and update table APIs to use your new function.