Here is a supplemental comment.
The condor job was submitted yesterday evening on the test server. To test the stability of the process, we left it all the night.
This morning, the condor job was in the hold state with the error message. Here is the error message in ~/public_html/summary/log/gw_daily_summary.log:

012 (093.000.000) 2024-10-30 07:03:52 Job was held.
        Job has gone over cgroup memory limit of 0 megabytes. Peak usage: 0 megabytes.  Consider resubmitting with a higher request_memory.
        Code 34 Subcode 0

The memory of the test server was 8 GB. We need much more memory to run the process of the summary page stably. Note that the memory in the k1sum0 (the current summary page is running there) is 128 GB. 

Alternative test server

We discussed the possibility of using a computer to test the summary page.

1. k1det0 (384 GB memory, 20 CPU): This computer is currently used to run Fscan and Hveto.
2. k1det1 (384 GB memory, 20 CPU): This computer is currently used to generate segment files and run Gauch
3. detchar cluster in the SK computer room. (128 GB memory): This computer is not ready to run the process. We need to set up the computer environment.

The k1det0 will probably be used to test the summary page by replacing the hard disk, after discussing yamaT-san.

Mystery of how to read frame data

The environmental variable to identify the NDS server on the workstation is set and named NDSSERVER or NDS2SERVER. We didn't set these variables when we tested the summary page on the test server. However, the process runs and succeeds in reading the frame data. It's better to make clear how to read the frame data in gwsumm.