よく間違える記述の例です。
不等式制約では、「今月」をDay集合とすることが多いです。制約中の「今月」の定義を見るには、マウスMiddleボタン（ホイールボタン）をクリックすると出てきます。
ちゃんと、今月になっていることが分かります。
下の例では、6連続勤務禁止のパターンで、先月部26日からの5日間が、正しく動くためには必要ですが、先月部2日間のみとなっており、指定を間違えていることが分かります。
Ans.
固定した勤務で、平日のみに出勤することが決まっているならば、スタッフに入れない方がよいです。スケジュールナースは、決まっていないシフトを割り当てるソフトです。
対象は出来る限り少なくした方が、求解速度は上がるので、上記目的外のスタッフは、下のようにチェックを外すか、行削除して、当該プロジェクトの対象スタッフではなくします。
Ans. 制約名は、何であってもよいです。スタッフ名である必要はなく、例えば、AとBとかでもOKです。他の制約と区別できることが唯一の条件です。
ですのでユニークな名前にしてください。
例
＜ペア制約について＞
現在、上記のように固有名を用いて記述は可能ですが、記述することは推奨しておりません。退職等でスタッフがいなくなるとエラーとなるためです。
GitHUBの挙げている例の通り、
スタッフプロパティシートは毎月メンテすると思いますので、忘れることは少ないと思います。
Ans.
マイクロソフトアカウントにログインして、
サブスクを停止してください。来月から課金されなくなります。
https://www.nurse-scheduling-software.com/japanese/service/pausing_subscription/
ご利用ありがとうございました。
Q.下図、宿日直回数と休日拘束数とで、医師間のばらつきがいつもより大きいような気がします。何故でしょう？
Ans. １２月勤務表では、１月年始も取り込んで作成している影響だと思います。（物理的要因です。）
試しに、制約最終日を１２月３１日に変更してみました。
上図をよく見比べると、医師間のバラつきは、
制約最終日 宿日直数 休日拘束数
１月５日版 2－４ 4－6
１2月31日版 0－2 2－4
となっており、バラつき（偏差＝２）で変わっていません。全体が多くなっている傾向になっているだけ、ということです。これは、制約日数が5日だけ増えている影響とみることが出来ます。
この勤務表のスタッフプロパティシートは、制約区間全体に効いてくるので、適宜最適値に調整してください。
変更前
また偏差も2以下に収まっています。
休日の丸1日の宿日直、あるいは休日拘束1回に対してカウントは、２です。つまり、回数に直すと1回の偏差となります。この1回の偏差は物理制約による限界です。全員が偏差0とするには、
Σ宿日直％医師数==0
になる必要があります。平たく言うと、端数が0になる必要があります。逆に言えば、全員が偏差0となるには、端数0となるときだけです。
例えば、宿日直コマ数総和40に対して、医師が10人いれば、全員4回で均等にできますが、41の場合は、割り切れず、必ず偏差が１となります。5回行う方が1人だけ生じます。
つまり、1回の偏差が生じるのは物理限界であって、なんら不思議ではありません。
大変、参考になる論文が出ました。
PDLPは、諦めていたのですが、GPU実装を使えば、可能性があることが示されています。最近のGurobiもGPUを使い始めたのは知りませんでした。
Simplex、内点法、FirstOrderの比較考証もされています。Simplexのマルチスレッド化は、LU分解のパラレル化が困難でした。Julian Hall教授の実装もありますが、CPUキャッシュに収まりきれないと性能が出ない問題があります。また、従来IPMにしてもスパースコルスキー分解を上手くGPUに載せるのは、難しいと考えられてきました。
ここにきて、FirstOrderは、激しく性能向上争いが続いていて、ADMMを用いた方法も注目しています。
以上のトレンドを鑑みて、GPUによる実装を検討してみようと思います。（あくまで記録更新用なので、一般の実装には影響しません。ABIP+にせよPDLPにせよ、ユーザにとっては、精度と速度が出れば何でもよいです。）
＜Simplexは必要ないか？＞
依然として必要です。なぜなら、HotStart（WarmStart）によく駆動は、Simplexによるからです。INRC2規模では、Simplexのhoststartによる方が速いのでSimplexは欠かせません。一方、超大規模、SchedulingBenchmarksのInstance23/24規模になると、SimplexはHotstartを使っても無力です。この場合、内点法かFirstOrderによる方法となります。（FirstOrderによるHotStartは、Starandmarkさんの論文にあるのですが、大して効果がなかったような印象が残っています。）
上記論文で使われているGPUは、とんでもなく高価なものですが、上のような背景の私の用途としては、普通の世代落ちしたもので十分効果があるだろう、と見ています。
CUDAが使えるＧＰＵは、以下のページで分かります。
CUDA GPUs - Compute Capability | NVIDIA Developer
とりあえず、GPUを購入して勉強・評価して、COPTを使用するかどうかを判断したいと思います。
AIの流行により、一気に花開いたGPUですが、アークテクチャを見ると、ハードウェアとソフトウェア（コンパイラ技術）の見事なバランス感覚で成り立っており、両分野に精通した人の設計なんだろうな、と思います。CPUでマルチスレッドにするとキャッシュメモリがボトルネックとなり、その部分を分離できるという意味においても一時の流行に終わることがなく、今後も汎用化が加速していくのでないかと推測します。
今まで、ユーザさまのPCにローカルファイルで保存することを推奨してきたのですが、その選択がなくなり、勝手にクラウドに録画される仕様に変更になったみたいです。
で、この録画、AI要約があったり、文字起こしがあったりで、再度見たい箇所を素早く探すことが出来るようです。ダウンロードではなく、パスコードリンクを送ることで、ユーザさまも文字起こし付のサイトで視聴できる、ということのようです。
AI要約は、次のレベルでまだまだ、です。
次は、昨日行ったAI要約です。
--
ミーティング後、ユーザさまにパスコード付きのリンクを私菅原氏とｘｘ氏は、クラウドレコーディングシステムの導入やスタッフの休暇管理、システムにおける制約の重要性について話し合いました。 また、スケジュール変更のプロセス、ソフトウェア制約の使用、スタッフ定義を設定し、過剰と不足を調整することの重要性にも焦点が当てられました。 会話は、新しいシステムの実装、複雑な制約に対応できるシステムの必要性、ソフトウェア制約を維持することの重要性について議論で終わりましたが送れば、ユーザさまの視聴が可能です。
菅原さんとｘｘさんは、Excelの使い方をｘｘさんに教えることに焦点を当てた4時間のセッションを行い、菅原さんが指導や制限事項を提供しました。 セッションは、菅原が後でｘｘにファイルを送ることを約束して終了しました。 両参加者は、このセッションに感謝の意を表しました。
--
プロジェクトファイルが、全く動かない状態からのスタートでした。なので、制約を一から作りこむレクチャを行いました。
■仕様の聞き取り・確認
■頂いたプロジェクトファイルをベースにしながら、一から制約を作りこんでいきました。
■特に留意する点、注意事項など、その都度、質問を受けながら
■全ての実装したい制約を実装
し、その場で、ブランク予定でエラー０まで実装確認を行いました。
知人からの紹介とのことで、「知人のプロジェクトファイルをベースに、サブスクをご契約頂いて著書も購入したけれでも、全くどうすればよいか分からない」
とのことでしたが、出来栄えにご納得頂けたと思います。気づけば４時間程経っていました。OJTで、なおかつプロジェクトファイルが出来上がりました。
勿論、ご自分で一から練習してみるのが最も大事、というお話しはさせていただきました。４時間分の録画はあるので、見たいところや聞き逃したところ等、見返すことが出来、これと併せて、その職場にマッチした最適な学習教材（当該プロジェクトの解説資料５０ページ添付）にもなったと思います。
が、これほど短時間に実装できるスケジュールナースは、
凄いな！スケジュールナース！
と改めて思った次第です。慣れれば最強は疑うところなし、です。
