कार्गो जहाज़ों के लिए गणितीय optimization तकनीक

 (research.google)
1 पॉइंट द्वारा GN⁺ 2024-06-07 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Google Research की Operations Research टीम ने Shipping Network Design API जारी किया है, जो नियमित container ships के network design, scheduling, और container routing को साथ में optimize करता है
  • यह समस्या जहाज़ों के port visit sequence, arrival-departure time, और containers के origin-destination route को एक साथ तय करती है, इसलिए इसकी जटिलता WorldLarge मानक पर 500 जहाज़ और 200 ports के पैमाने तक पहुँच जाती है
  • शुरुआती approaches, double column generation और CP-SAT, छोटे और मध्यम आकार की समस्याओं में provable optimal solutions ढूँढ सके, लेकिन बड़े पैमाने की समस्याओं के लिए large neighborhood search और variable neighborhood search को मिलाने वाली heuristic की ज़रूरत पड़ी
  • LINERLIB benchmark में WorldSmall, EuropeAsia, Pacific, और Mediterranean के container throughput में क्रमशः 35%, 14%, 35%, 32% की वृद्धि हुई, जबकि उपयोग किए गए जहाज़ों की संख्या 7%, 15%, 4%, 23% घटी
  • Google का कहना है कि यह तरीका WorldLarge स्तर के network design और scheduling problem को हल करने वाला पहला तरीका है, और Shipping Network Design API को आगे चलकर Operations Research APIs के हिस्से के रूप में उपलब्ध कराया जाएगा

container shipping network को एक साथ optimize करने की समस्या

  • दुनिया के 90% सामान समुद्र के रास्ते चलते हैं, और बड़े cargo ships की लंबाई 0.25 mile, वज़न 2.5 लाख ton, क्षमता 12,000 containers, और कुल 1 अरब dollar मूल्य के cargo तक हो सकती है
  • cargo ships, aircraft, trains, और trucks के विपरीत, लगभग लगातार चलते रहते हैं और समुद्र में circular routes का पालन करते हैं
  • अक्षम routes और schedules के कारण containers ports पर रुके रहते हैं, जहाज़ समुद्र में इंतज़ार करते हैं, logistics flow धीमा होता है, और इसका असर उत्पादों की कीमतों पर भी पड़ता है
  • Google का Shipping Network Design API इस समस्या के लिए एक नया समाधान लागू करता है
    • यह पहले से ज्ञात प्रयासों की तुलना में तेज़ है और बेहतर scale करता है
    • यह container shipping कंपनियों का लाभ दोगुना कर सकता है, 13% अधिक containers ढो सकता है, और 15% कम जहाज़ों के साथ संचालन संभव बनाता है

LSNDSP में साथ हल किए जाने वाले तीन निर्णय

  • Liner Shipping Network Design and Scheduling Problem, यानी LSNDSP, तीन तरह के निर्णयों को एक साथ संभालता है
    • network design: जहाज़ किन ports पर किस क्रम में जाएंगे, यह तय करना
    • network scheduling: जहाज़ कब पहुँचेंगे और कब रवाना होंगे, यह तय करना
    • container routing: containers origin से destination तक किस यात्रा-पथ से जाएंगे, यह चुनना
  • container shipping कंपनियों को ये तीनों समस्याएँ हल करनी पड़ती हैं, लेकिन आम तौर पर इन्हें क्रमवार सुलझाया जाता है
  • इन तीनों को एक साथ हल करने से कठिनाई बढ़ती है, लेकिन बेहतर solution मिलने की संभावना भी बढ़ती है
  • network design का परिणाम कुछ जहाज़ों द्वारा साझा की जाने वाली service lines के रूप में सामने आता है
    • उदाहरण के लिए, यह East Asia से Suez Canal होकर Southern Europe तक जाने वाला route हो सकता है
    • service lines को तारीखों के साथ प्रकाशित किया जाता है ताकि shippers को पता हो कि container कब और कहाँ तैयार रखना है

port berthing, transshipment, और delay से बनने वाली constraints

  • container ships जब चाहें तब port पर berth नहीं कर सकते; उन्हें पहले से तय berthing slots का उपयोग करना होता है
  • जहाज़ port के पास पहुँचने के बाद berth उपलब्ध होने तक anchorage area में anchor डालकर इंतज़ार कर सकते हैं
    • port व्यस्त होने पर उन्हें कई घंटे या कई दिनों तक anchorage में रुकना पड़ सकता है
  • सटीक network schedule का मतलब सिर्फ किस दिन berth मिलेगा यह नहीं, बल्कि किस समय berth मिलेगा यह भी है
    • किसी खास समय तक पहुँचने के लिए जहाज़ speed बढ़ा सकता है
    • fuel बचाने के लिए speed कम करने का विकल्प भी संभव है
  • port पर berth होने के बाद cranes containers उतारती हैं और अगली यात्रा के लिए लादे जाने वाले containers फिर से जहाज़ पर चढ़ाती हैं
  • अगर schedule पीछे खिसक जाए तो cut-and-run की स्थिति आ सकती है, जिसमें जहाज़ तय containers पूरी तरह लादे बिना ही port छोड़ देता है
    • बचे हुए containers बाद में आने वाला कोई दूसरा जहाज़ ले जाता है
  • जब कोई container origin से destination तक जाते हुए बीच के port पर समय बिताता है, तो उसे transshipment कहा जाता है
    • transshipment, LSNDSP में संभावित solutions की संख्या और बढ़ा देता है
    • यह container routes बनाने में काम करने वाली कई constraints में से एक है

optimization method: column generation से neighborhood search तक

  • हर optimization problem variables, उन variables पर constraints, और minimize या maximize किए जाने वाले objective function से बनी होती है
    • उदाहरण: जहाज़ और ports variables हैं
    • उदाहरण: जहाज़ पर लादे जा सकने वाले containers की संख्या एक constraint है
    • उदाहरण: ढोए गए containers की संख्या को अधिकतम करना objective function है
  • variables और constraints को आम तौर पर matrix के रूप में व्यक्त किया जाता है, जहाँ columns variables और rows constraints को दर्शाती हैं
  • बड़े पैमाने की समस्याओं को विभाजित करने की एक सामान्य तकनीक column generation है
    • शुरुआत में variables के केवल एक हिस्से को लिया जाता है
    • फिर मूल समस्या का बेहतर approximation पाने के लिए नए variables, यानी नए columns, बनाए जाते हैं
  • Google ने समस्या का विश्लेषण करके यह अनुमान लगाने वाली software library विकसित की कि कौन से columns बनाना बेहतर होगा
    • यह library mathematical programming framework MathOpt के ज़रिए open source के रूप में जारी की जाएगी

दो बुनियादी approaches की सीमाएँ

  • double column generation network design और container routing को दो आपस में जुड़े हुए problems के रूप में देखता है
    • हर problem एक master selection problem और बेहतर विकल्प खोजने वाली auxiliary generation problem से बनी होती है
    • हर problem pair पर shortest-path algorithm लागू करके उपयुक्त विकल्प तैयार किए जाते हैं
    • इसके बाद linear programming solver Glop का उपयोग करके हर problem के लिए सबसे अच्छा विकल्प चुना जाता है
    • दोनों problems पर एक साथ column generation लागू किया जाता है, और एक problem के intermediate results दूसरे की प्रगति को प्रभावित करते हैं
    • यह provable optimal solution ढूँढ सकता था, लेकिन केवल medium-scale problems तक ही अच्छी तरह scale कर पाया
  • CP-SAT आधारित implementation भी आज़माया गया
    • इसमें Google का constraint programming solver CP-SAT इस्तेमाल किया गया
    • यह medium-scale networks तक ठीक चला, लेकिन global shipping problem के पैमाने तक scale नहीं कर पाया
  • दोनों approaches छोटे और मध्यम आकार की समस्याओं में provable optimal solutions तक पहुँचे, लेकिन बड़े पैमाने पर scalability की कमी रही

बड़े पैमाने पर scale करने के लिए heuristics

  • scalability बढ़ाने के लिए local search के दो variants लागू किए गए, जो मौजूदा solution के आसपास के neighborhoods को देखकर सुधार के अवसर खोजते हैं
  • large neighborhood search solution के कुछ हिस्सों को fix करके ऊपर बताए गए तरीकों को लागू करता है
    • उदाहरण: “यह जहाज़ हर दूसरे मंगलवार Los Angeles जाएगा” जैसी शर्त को fix किया जा सकता है
    • इससे search space घटता है और scalability बढ़ती है
  • variable neighborhood search network और scheduling दोनों के neighborhoods को explore करता है
    • search को parallel किया जाता है और कई machines पर बाँटकर एक साथ बहुत से neighborhoods का evaluation किया जाता है
    • इससे search space सीमित रखते हुए Operations Research और shipping industry का domain knowledge शामिल किया जा सकता है
  • दोनों approaches promising solution के कुछ हिस्सों को lock करके, पहले से अच्छे solution से शुरू करते हुए उसे और बेहतर solution में बदलने वाली incremental approach अपनाते हैं
  • पहले के प्रयास transport time को शामिल नहीं करते थे, क्योंकि उससे problem सुलझाना बहुत कठिन हो जाता था, लेकिन Google ने पाया कि transport time शामिल करने से solution quality में बड़ा सुधार होता है

LINERLIB benchmark के परिणाम

  • performance evaluation के लिए shipping network design problems के industrial benchmark LINERLIB का उपयोग किया गया
    • benchmark में container shipping scenarios के fleets, ports, और container demand शामिल हैं
  • test scenarios में WorldSmall, EuropeAsia, और WorldLarge शामिल थे
    • WorldLarge में 500 जहाज़, 200 ports, और लगभग 1.4 लाख containers शामिल हैं
  • optimization का उद्देश्य सिर्फ containers की संख्या अधिकतम करना या जहाज़ों की संख्या न्यूनतम करना नहीं है
    • अगर सिर्फ containers अधिकतम किए जाएँ, तो ज़्यादा जहाज़ लगाने पड़ सकते हैं और operating cost बढ़ सकती है
    • अगर सिर्फ जहाज़ों की संख्या न्यूनतम की जाए, तो एक ही जहाज़ से सभी containers ढोने जैसी अवास्तविक रूप से लंबी delivery times बन सकती हैं
  • LINERLIB समय पर delivery से होने वाली आय में से voyage cost और port container handling cost घटाकर अनुमानित profit के आधार पर संतुलन बनाता है
  • baseline की तुलना में Google का तरीका कम जहाज़ों के साथ अधिक containers को route करता है
    • WorldSmall: container throughput 35% बढ़ा, जहाज़ों की संख्या 7% घटी
    • EuropeAsia: container throughput 14% बढ़ा, जहाज़ों की संख्या 15% घटी
    • Pacific: container throughput 35% बढ़ा, जहाज़ों की संख्या 4% घटी
    • Mediterranean: container throughput 32% बढ़ा, जहाज़ों की संख्या 23% घटी
  • LINERLIB की आर्थिक मान्यताओं के आधार पर अनुमानित profit rate में भी उल्लेखनीय सुधार दिखा

API और आगे की सामग्री

  • Google इस तरीके को WorldLarge स्तर की network design और scheduling problem हल करने वाला पहला तरीका मानता है
  • परिणामों को LSNDSP benchmark page पर और विस्तार से देखा जा सकता है
  • Shipping Network Design API आगे जोड़ी जाने वाली Operations Research APIs में से एक है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2024-06-07
Hacker News की राय

  • मैं इस industry के terminal side में हूं, और यह दिलचस्प तो है, लेकिन बहुत academic लगता है
    सोच रहा हूं कि क्या इसे सच में shipping lines के साथ मिलकर बनाया गया है। Terminal side पर हम अभी container optimization में काफी गहराई तक गए हुए हैं, और यह सचमुच nightmare जैसा है। एक ही company के स्वामित्व वाले terminals के बीच भी operations का तरीका काफी अलग होता है, और अक्सर terminology भी company के अंदर अलग-अलग होती है। किसी एक terminal के लिए optimize कर भी दें, तो अगले terminal में 80% चीजें फिर से बनानी पड़ती हैं, इसलिए कोई भी solution scale करना बहुत मुश्किल है

    • Industrial optimization problems देखने पर हमेशा लगता है कि बहुत सारा पैसा यूं ही पड़ा है, लेकिन असल में undocumented human-centric constraints चीजों को बहुत जटिल बना देते हैं
      उदाहरण के लिए German engineers production से पहले vehicles के features lock करने का विरोध करते थे, क्योंकि तब वे उन्हें leisure use के लिए इस्तेमाल नहीं कर पाते। Healthcare में overtime costs अरबों के स्तर पर जा रही थीं, इसलिए scheduling improvements आसान लगते थे, लेकिन union constraints बहुत थे और hiring supply भी कम थी। Google का solution कितना realistic है, यह जानने की उत्सुकता है। क्या Houthi missiles जैसी constraints भी शामिल हैं? मेरे experience में provable optimum से ज्यादा value अक्सर ऐसे solution में होती है जो unexpected changes के हिसाब से आसानी से adjust हो सके
    • Performance evaluation में इस्तेमाल किया गया benchmark data Maersk से आया है: https://github.com/blof/LINERLIB
    • Shipping में नहीं, लेकिन manufacturing में 15 साल काम किया है; मुख्य रूप से test engineering और automation, साथ ही warehouse/materials management और transportation/logistics भी संभाला है। मेरा master's manufacturing operations research में था
      मैं सहमत हूं कि objective optimization ज्यादातर academic होता है। किसी standardized process के सबसे efficient version को जस का तस follow करना कठिन या असंभव क्यों है, इसकी वजह हमेशा होती है। कभी-कभी ये लोगों की वजह से पैदा हुए “मूर्खतापूर्ण” कारण होते हैं, और अक्सर weather, downtime, supply-chain disruptions, seasonality के चलते demand signals और forecasts की unevenness जैसी externalities को दर्शाने वाले तर्कसंगत कारण होते हैं। फिर भी मुझे लगता है कि known exceptions के आधार पर standard process बनाने की बजाय, सबसे efficient process से शुरू करके exception handling जोड़ना लगभग हमेशा बेहतर है। अगर exceptions को ही rule बनने दें, तो आप हमेशा optimum से कम efficient तरीके से operate करेंगे
    • मैं भी terminals और inland transportation companies के साथ काम करता हूं। Load planning optimization, berth allocation, crane split जैसे “cool-looking” academic problems हल करने की कोशिश करने वाले बहुत लोग हैं, लेकिन वास्तव में implement बहुत कम होते हैं
      यह industry कठिन है, और port workers' unions पारंपरिक रूप से मजबूत रही हैं, इसलिए political landscape और भी मुश्किल है। जिन problems को साफ-साफ अलग करके नाम दिया जा सकता है, वे असल में एक-दूसरे से उलझी हुई होती हैं, और अगर यह उम्मीद हो कि algorithm users के लिए “जादू की तरह” उन्हें हल कर देगा, तो अक्सर असफलता मिलती है। “बस traveling salesman problem / constraint solver / मनचाहा approach चला दो न?” सोचकर कूद पड़ने वाले software heavyweights को यह industry आसानी से निगल जाती है। Smart लोगों की जरूरत जरूर है, लेकिन विनम्रता से शुरुआत करनी चाहिए और पहले real users से बात करनी चाहिए। Profile में contact info नहीं दिख रही, लेकिन अगर इस industry की दूसरी company के साथ विचार साझा करना चाहें तो mail भेजें। खासकर intermodal share ज्यादा वाले सालाना 1 million TEU से कम terminals segment में हम रोचक काम कर रहे हैं
    • इस field के बाहर के लोगों के लिए, क्या आप अपने मौजूदा काम के बारे में थोड़ा और detail में बता सकते हैं?

  • मैं containerization के शुरुआती इतिहास पर लिखी The Box पढ़ रहा हूं, और यह सच में बहुत मजेदार है
    Engineering, design, business और history का mix ढूंढ रहे लोगों के लिए जोरदार recommendation है। यह मेरे छोटे-मोटे coding problems को भी हास्यास्पद बना देती है

    • शानदार किताब है और recommendation से सहमत हूं
      बहुत rebuttals आएंगे शायद, लेकिन ईमानदारी से कहूं तो मुझे लगता है कि 20-foot shipping container का दुनिया पर जो impact पड़ा है, वह large language models के भविष्य में हासिल कर सकने वाले impact से भी बड़ा था। पहले वह किताब पढ़ें और फिर बताएं कि मैं गलत क्यों हूं। हालांकि, मैं गलत नहीं हूं
    • “The Box” का Wikipedia article: https://en.m.wikipedia.org/wiki/The_Box_(Levinson_book)
    • Flexport में new hires को यह किताब दी जाती थी। कम से कम कुछ साल पहले तक तो ऐसा था

  • लगता है कि बहुत बड़े fleets में container optimization अभी भी unsolved problem था। मुझे पता नहीं था
    अगर Google operations research ने existing solutions की तुलना में utilization 10–20% improve किया है, तो यह कमाल की बात है

    • यह packing problem जैसा लगता है। मैं इस field को गहराई से नहीं जानता, लेकिन समझता हूं कि इसका कोई general solution नहीं है
      https://en.wikipedia.org/wiki/Packing_problems

  • सच में बहुत curiosity है कि इस publicly released API endpoint को कोई actual में use करता होगा या नहीं: https://developers.google.com/optimization/service/shipping/...
    फिर भी काफी cool है

    • Google Cloud में 2015–2023 तक काम करने के professional experience के आधार पर, ऐसे operations research APIs 1) academic होते हैं, और 2) उनका commercial use ज्यादातर Google Cloud solution architects और engineers द्वारा GCP पर चलने वाले customer-specific business solutions बनाने में होता है
      एक प्रमुख example Route Optimization API है, जिसे enterprise operations research team ने इसी तरह public किया था, और बाद में कुछ alpha customers के input के आधार पर उसके ऊपर Fleet Engine solution बनाया गया। जब तक operations research APIs Google Cloud के जरिए expose नहीं होते, उनमें SLA या reliability guarantees नहीं होतीं, इसलिए मुझे लगता है कि academic use के अलावा इन्हें इस्तेमाल न करना बेहतर है। बस मेरी राय
      https://developers.google.com/maps/documentation/transportat...
    • कोशिश न करना उल्टा irresponsible भी हो सकता है। उत्सुकता है कि क्या यही planners के सामने आने वाली problems और constraints का पूरा shape है। Flexport इस field में SF-based $3.3 billion revenue वाली company है
    • Google का graveyard[1] तेजी से बढ़ रहा है, इसलिए नए Google announcements को लेकर मैं सावधान रहता हूं। ऐसे APIs future में replace करने पड़ें तो खास तौर पर बड़ी problem बन सकते हैं
      [1]: https://killedbygoogle.com/

  • अगर demurrage को ध्यान में नहीं रखा गया है, तो पता नहीं यह सच में आज़माने लायक है या नहीं
    https://developers.google.com/optimization/service/reference...

  • Omega Tau Podcast ने container shipping पर एक बहुत अच्छा episode[0] निकाला था, जिसमें container placement optimization और route planning भी कवर किए गए हैं। ज़ोरदार सिफ़ारिश
    [0]: https://omegataupodcast.net/146-container-shipping/

  • “हवाई जहाज़ों के उलट, cargo ships लगभग लगातार चलते रहते हैं” वाली बात पर थोड़ा सवाल उठाया जा सकता है
    cargo ships यात्रा के दौरान maintenance काफ़ी करते हैं, लेकिन इसके अलावा फ़र्क कहीं कम लगता है। बंदरगाहों पर वे कई दिनों में unloading और loading करते हुए turnaround करते हैं, और berth का इंतज़ार करते हुए कई घंटे या कई दिन तक खड़े भी रहते हैं। Delta A350 का उदाहरण देखें, तो airport पर 3 घंटे के turnaround को छोड़ दें तो यह असल में 24 घंटे चलता रहता है: https://www.flightradar24.com/data/aircraft/n513dz

    • unloading के दौरान भी इसे “operating” कहा जा सकता है, ऐसा लगता है

  • इससे याद आता है कि मोहल्ले के restaurant जैसी जगहों के मालिक या managers कहते हैं कि part-time staff का schedule बनाना सिरदर्द है, और यहाँ तक कहते हैं कि उन्हें ज़्यादा salary मिलने की वजह भी यही है
    मुझे लगा था कि इसे algorithms से solve किया जा सकता है

    • बहुत से लोगों को अपने working hours में बड़ा बदलाव पसंद नहीं होता
      जिस रात आधे कर्मचारी Taylor Swift देखने गए हों, उसे cover किया जा सकता है, लेकिन अगर आप लोगों को इस तरह बुला लेते हैं, तो उन लोगों की अगली shifts भी फिर किसी और को cover करनी पड़ेंगी, और यह सिलसिला चलता रहा तो schedule पूरी तरह अलग लोगों से बन जाएगा जिन्होंने शायद कभी साथ काम भी न किया हो। और constraints जोड़कर इसे ठीक किया जा सकता है, लेकिन उन सबको लिखना और priorities तय करना ही आसान नहीं है। लोग Lego blocks नहीं हैं
    • यही वह समस्या है जिसे मैं ठीक-ठीक solve करना चाहता हूँ। schedule बनाने वाले लगभग हर व्यक्ति से यही कहानी सुनता हूँ
      मेरा background operations research में है, इसलिए यह हमेशा अजीब लगता है। ये problems general-purpose solvers से model और solve करने के लिए सरल लगती हैं, और advanced techniques के बिना भी इनकी value बड़ी दिखती है। समस्या यह है कि operations research कुल मिलाकर बहुत accessible नहीं है। अच्छी तरह supported अधिकांश solvers समस्या को mathematical paradigm में define करने को कहते हैं, जिसे “आम आदमी” देखते ही overwhelmed हो जाता है। आम scheduling problems के लिए ready-made solutions भी हैं, लेकिन अगर उन्हें शुरू से इस्तेमाल नहीं किया गया हो तो हर workplace में अपनी unique variations होती हैं, जिससे पूरा adoption मुश्किल हो जाता है। या तो वे उस variation को support नहीं करते, या पता नहीं चलता कि उसे tool के अंदर कैसे fit करें। schedule को बेहतर तरीके से solve करने की इच्छा हो भी, तो मिलने वाले courses आमतौर पर काफ़ी programming या math की prior knowledge मानकर चलते हैं। मुझे लगता है कि scheduling problems के लिए ऐसा no-code modeling environment बनना चाहिए जिसे “आम लोग” भी इस्तेमाल कर सकें—जहाँ Excel कम पड़ता है, लेकिन operations research expert को hire करना संभव नहीं होता
    • यह सचमुच महत्वपूर्ण समस्या है, और बहुत सा software पहले से इसे handle कर रहा है
      लगभग हर बड़े HR/workforce management system में इससे जुड़े options होते हैं। उदाहरण के लिए https://www.workday.com/en-us/products/workforce-management/... और https://www.oracle.com/human-capital-management/workforce-ma... हैं, और dedicated vendors भी बहुत हैं। हालांकि जैसा किसी और ने कहा, ये systems विवादित भी रहे हैं। वजह यह है कि कुछ का इस्तेमाल सामान्य मानवीय जरूरतों को ध्यान में न रखने वाले तरीके से होता है। जैसे लगातार shifts assign करना, short notice पर schedules बदलना, या childcare जैसी वास्तविक परिस्थितियों को ध्यान में न रख पाना जिन्हें कोई human manager शामिल कर सकता था
    • उसी operations research group में restaurant के लिए scheduling example है: https://developers.google.com/optimization/service/schedulin...
    • combinatorial optimization का थोड़ा background होने के कारण मैंने इस क्षेत्र या school timetable planning जैसे software आज़माने के बारे में सोचा था
      लेकिन समस्या यह है कि हर workplace के constraints अलग होते हैं। जैसे किसी एक shift में कम से कम 1 व्यक्ति first aid देने में सक्षम होना चाहिए, या Alice और Bob की बनती नहीं है, या लगातार 2 हफ़्ते Saturday को काम नहीं करना चाहिए, या shifts हर 2 हफ़्ते में बदलती हैं, या shifts के बीच कम से कम 12 घंटे होने चाहिए। जो tool इतने flexible हों कि काफ़ी organizations उनका इस्तेमाल कर सकें, वे अंत में शायद इतने complex हो जाएँ कि इस्तेमाल करना मुश्किल हो जाए

  • ऐसे जहाज़ों की stowage plan अब भी जिज्ञासा का विषय है
    हर container की route planning के बाद वाले चरण में यह शायद ऐसा problem होगा जिसे approximate तरीके से solve करना पड़ता है। stowage plan बाद में आता है, और global system-level perspective की तुलना में इसमें बहुत अधिक situation-dependent constraints होते हैं। मोटे तौर पर optimistically देखें तो quay crane प्रति घंटे 30–50 moves करता है, हर जहाज़ पर 2 या 4, ज़्यादा हुआ तो 6 cranes लगते हैं, और layers को खोल की तरह परत-दर-परत खोलना पड़ता है। Ultra Large Container Vessel 14,501 TEU या उससे ऊपर, New Panamax 10,000–14,500 TEU, Post-Panamax 5,101–10,000 TEU, और Panamax 3,001–5,100 TEU होता है। अगर 24,000 TEU को 40-foot containers के 12,000 units मानें, तो 4 cranes × प्रति crane प्रति घंटे 50 containers × 24 घंटे = लगभग 1,200 containers प्रति दिन होता है।
    https://en.wikipedia.org/wiki/Stowage_plan_for_container_shi...
    ship stowage planning में port पर availability के अलावा weight, balance, power और cargo value acceptance criteria भी होते हैं। लेख में port से early departure का ज़िक्र था, इसलिए इस तरह के overhead को लेकर जिज्ञासा हुई और मैंने एक rough calculation की

    • Technical University of Denmark(DTU) के एक researcher का online lecture है, जो stowage problem के intro के तौर पर काफी अच्छा है: https://www.youtube.com/watch?v=9ltz4G-lPdg
      इस field में सच में शामिल व्यक्ति के नज़रिए से देखें तो, अपने काम को आसान बनाने के कई तरीके हैं। hatch cover के हिसाब से block units में plan करना, और containers को destination, size और weight के आधार पर group करके interchangeable मानना basic है। फिर काम शुरू होने से पहले ship से terminal को plan भेज दिया जाए, तो terminal भी yard में containers की location जानता है, इसलिए optimization और reshuffling कर सकता है। अगर हर container की detailed बातें ignore करके सिर्फ groups पर focus करने का फैसला करें, तो stowage planning काफी आसान हो जाती है। बहुत कम काम में result लगभग वैसा ही मिलता है, और terminal को operations optimize करने की flexibility भी ज़्यादा मिलती है