テストです

hope366さんが投稿できないようですが、文字数でひっかかるというのはおかしいですね。１行でも投稿できるのならブロックされてないわけですし。
念のため、すべてのファイルをアップロードし直しました。

こんなの保存しなくていいよ！、という場合は、default_gtp.cfgで解除できます。
default_gtp.cfgを開いて、比較的上のほうに、# Logs and files-----　というのがあり、そのすぐ下に、
logDir = gtp_logs
# logFile = gtp.log
というのがあります。これは、katagoを実行した時の動作履歴を「gtp_log」というフォルダに記録させるための命令文です。
これを次のように変更します。
# logDir = gtp_logs
# logFile = gtp.log
行の先頭に「#」をつけることによって、以降の命令文が無視される（無効になる）みたいな感じですね。
下段の「# logFile = gtp.log」は、gtp_logフォルダに個別に保存するのではなく、katagoを別々に実行したとしても、gtp.logというファイルにまとめて保存するようにするための命令文です。
両方とも有効にすると、両方とも機能するのではなく、エラーになってlizzieでもSabakiでも動かなくなります。

で、今回のkatago-v1.4.4の変更は下段の「logFile = gtp.log」を有効にした場合の話です。
有効になっている設定を、lizzieやSabakiで「-override-config logFile=」を使うことによって個別に無効にすることができるようになりました、ということです。

メガパックのSabakiのkatagoのArgument（引数）は「gtp -override-config ponderingEnabled=false,maxVisits=200000 -model KataGo20b.gz」
のようになっていますが、ここを、
「gtp -override-config logFile=,ponderingEnabled=false,maxVisits=200000 -model KataGo20b.gz」のように変更します。
「logFile=」を追加しました。logFileの指定に空の文字列を適用することで、gtp.logファイルの自動生成が無効になります。

lizzieの場合だと、config.txtのengine-command欄、もしくは起動してから「設定」→「エンジン」で表示されるエンジンコマンド指定文の一覧表で、katagoのエンジンコマンド文をSabakiの時と同じように変更します。
例えば、"engine-command": "./katago-v1.4.4/katago.exe gtp -model KataGo40b.gz -config ./katago-v1.4.4/default_gtp.cfg",を、
"engine-command": "./katago-v1.4.4/katago.exe gtp -override-config logFile= -model KataGo40b.gz -config ./katago-v1.4.4/default_gtp.cfg",
のように変更します。これでlizzieフォルダにgtp.logファイルが自動生成されなくなります。

-override-config というのは、cfgファイルで指定した命令文を上書き指定するためのコマンドで、katago-v1.3.3から使えるようになりました。
例えば、katago-v1.4.4のデフォルトの訪問数の上限は、default_gtp.cfgによって「maxVisits = 500」となっていますが、SabakiのArgument欄で、
「-override-config maxVisits=200000」を追加指定することで、訪問数の上限が500から20万になります。

hope366さん

ありがとうございます。

KataGoを使っている限り v1.4.4が以前のバージョンと何が変わったか全く分からなかったのでお聞きしました。

「gtp_logs 」って初めて開きました。
使った日時でテキストファイルが並んでいますね。

投稿するのが何か困難なご様子なのにいつもすみません。

ついでに一つ、コマンドとか何もせずgtp.logファイルの自動生成が有効なままで使い続けても問題はないですよね。

gtp_logsや、gtp.logの中身は上書きされることでどんどん増えていきますが、普通に使っている分には何も問題はないと思います。
私は全部削除した上でオフ設定にしています。

今回はlogFileに関することでしたが、次はベンチマークテストにおける-tuneの初期装備や、homeDataDirに関することを調べていきます。

2番目の変更点である「homeDataDir」についてです。

katago-v1.4.2以前のバージョンでkatagoのopclバージョンをlizzieやSabakiで起動すると、初回起動時に限りチューニング作業が入り、katago.exeがあるフォルダに「KataGoData」というフォルダが自動作成されます。
このフォルダの中には、katago.exeを起動した際のチューニングに関するファイルが格納されています。
私の環境だと「tune6_gpuGeForceRTX2060_x19_y19_c256_mv8」というファイルが格納されています。

このファイルが存在することにより、次回起動時に要する時間が大幅に短縮されます。
私の環境だと、lizzie,Sabaki共に、初回起動時は約8秒程度かかっていたのが、2回目以降はわずか1秒くらいで起動するようになりました。
この「KataGoData」フォルダは削除することもできますが、削除してからkatagoを実行すると、初回起動時のときと同じように約8秒かけてチューニング作業を行い、「KataGoData」フォルダが作成されます。

katago-v1.4.4では、default_gtp.cfgの# Logs and files------の一番下に、# homeDataDir = DIRECTORYというのが追加されています。
ここに任意のフォルダ名やパスを指定することで、今まで自動でkatago.exeと同じ場所に「KataGoData」フォルダが作成されていたものが、任意の場所や任意のフォルダ名で作成されるようになりました。

例えば、homeDataDir = yyy　と指定してkatagoを実行すると、約8秒かけてチューニング作業を行い、katago.exeと同じ場所に自動的にyyyというフォルダが作成されます。
既存の「KataGoData」フォルダはそのままでです。
また、homeDataDir = C:\badukのようにパス名を指定すると、badukフォルダに「opencltuning」というフォルダが作成されて、この中にチューニングに関するファイルが格納されます。

任意のフォルダ内で「右クリック→プロパティ→セキュリティ」で、そのフォルダへのアクセスに関する詳細な設定ができます。
何らかの理由でkatagoフォルダが書き込み禁止になっていても、homeDataDirを使えば他の場所にチューニングファイルを作成することができ、毎回時間をかけて起動する手間が省けますね。
一台のPCを複数の人が利用したり、教室などで単一のPCの設定を大勢で共有したりする場合に便利な機能ですね。

次は、「マイナーなUIの変更と機能」の3番目の変更点である「The benchmark command now runs in -tune mode by default.」です。

katagoのベンチマークテストを行う際のデフォルトの命令文は、
katago benchmark -model KataGo20b.gz -config default_gtp.cfg
のような感じですが、このように追加コマンドを加えずに必要最低限の入力で実行すると、
スレッド数：1,2,4,6,8,12,16,24のベンチマークテストが実行されます。
この結果、もし24スレッドが最大のパフォーマンスであった場合は、当然24スレッドに推奨表示がつきますが、24スレッドより大きいスレッド数が最大パフォーマンスである可能性があります。
その場合は、再度、katago benchmark -model KataGo20b.gz -config default_gtp.cfg -t 24,36,48,60,72,84,96 などのようにスレッド数を指定してテストしたほうがいい、という話になります。
katago-v1.4.2以前のバージョンだと、このような手間を省くために「-tune」を追加してやる必要がありました。

katago benchmark -model KataGo20b.gz -config default_gtp.cfg -tune
とすることで、今度は上記のように1スレッドから順番に行うのではなく、5、10、12、20、16、24、32、のように（私の環境だとこうなりました）、
テストされます。（おそらく効率を考えて、1、2、4などは省いていると思われます）
そしてこの結果、仮に32スレッドが最大パフォーマンスであった場合は、
Optimal number of threads is fairly high, tripling the search limit and trying again.
（最適なスレッド数はかなり多く、検索制限を3倍にして再挑戦）と表示され、自動的に大きなスレッド数を適用してのテストが開始されます。
このように「-tune」を使うことで、一度の実行で推奨スレッド数を確認することができます。

最新バージョンのkatago-v1.4.4では、この「-tune」がデフォルトで適用されるようになりました。
katago benchmark -model KataGo20b.gz -config default_gtp.cfg
を実行すると、「-tune」の効果が自動的に発揮されて、一度の実行で推奨スレッド数が分かるようになりました。