Conversie, en im- en export van indelingsgegevens

Conversie en im- en export

1.	Genereer fysieke vlakken uit het geheel van converteerbare subcompartimenten
2.	Pas adviesinstelling voor het converteren naar fysieke vlakken toe
3.	Importeer PIAS compartimenten uit pre-2012 formaat
4.	Schoon pre-2012 PIAS compartimenten op
6.	Exporteer schotten en dekken naar Rapid Prototyping file (STL)
7.	Exporteer naar Poseidon (DNV•GL)
8.	Schrijf XML bestand
9.	Lees XML bestand

Genereer fysieke vlakken uit het geheel van converteerbare subcompartimenten

Deze optie doet vier dingen. In de eerste plaats wordt een overlappingscontrole uitgevoerd volgens, die volkomen identiek is aan de tweede optie in dit menu (zie Pas adviesinstelling voor het converteren naar fysieke vlakken toe), waarbij subcompartimenten van het type ‘ontstaan tussen vlakken’ kunnen worden omgezet naar het type ‘met coördinaten’. Bij deze test wordt ook gekeken of subcompartimenten elkaar overlappen, en als dat zo is dan wordt van één van die twee, en wel het kleinste, z'n ‘converteerbaarheid’ uitgezet, zodat deze wordt weggelaten bij de conversie. Vervolgens worden alle fysieke vlakken weggegooid, waarna op grond van de subcompartimenten van het type ‘met coördinaten’ een nieuwe verzameling fysieke vlakken wordt gegenereerd die onderling precies die subcompartimenten opspannen. Tenslotte worden al die subcompartimenten omgezet naar het type ‘ontstaan tussen vlakken’. Het is niet verplicht om alle aanwezige compartimenten te gebruiken bij deze actie; d.m.v. de instelling ‘convertible’, die opgegeven kan worden in de compartimentenlijst (zie Compartimentenlijst, berekenen en afdrukken van tanktabellen), bij de compartimentsdefinitie (zie Converteerbaar) en de subcompartimentsdefinitie (zie Converteerbaar) kan men heel precies aangeven welke (sub-)compartimenten wel en welke niet meegenomen moeten worden in deze conversie.

Attentie

Men wordt geadviseerd om met beleid gebruik te maken van deze conversieoptie. Het kan verleidelijk zijn om een heel schip, met al z'n compartimenten en tankjes, om te zetten naar de combinatie van fysieke vlakken en het subcompartimentstype ‘ruimte ontstaan tussen vlakken’, en dat kan ook wel, en het mag ook best, maar men eindigt dan allicht met een grote hoeveelheid fysieke vlakken, zonder enig overzicht, zodat men er uiteindelijk niet zoveel aan heeft. Het is wellicht verstandiger om zich bij het converteren een beetje te beperken tot compartimenten die tot de hoofdindeling van het schip behoren, en wordt daartoe ook gestimuleerd omdat het maximum aantal te converteren subcompartimenten 150 bedraagt (wat overigens geen principiële grens is, maar een praktische). Lees wat dit betreft ook nog eens na wat bij Gebruik van de diverse soorten subcompartimenten geschreven is.

Pas adviesinstelling voor het converteren naar fysieke vlakken toe

Deze optie is bedoeld ter ondersteuning van het genereren van fysieke vlakken uit subcompartimenten van het type ‘met coördinaten’ (zie Genereer fysieke vlakken uit het geheel van converteerbare subcompartimenten), dat is namelijk alleen maar mogelijk met niet-overlappende subcompartimenten. In de eerste plaats wordt hier gekeken of er al subcompartimenten bestaan van het type ‘ruimte ontstaan tussen vlakken’, en als dat het geval is dan wordt de gebruiker gevraagd of deze moeten worden omgezet naar het type ‘met coördinaten’, want het genereren van fysieke vlakken kan alleen op basis van dit type subcompartimenten. Vervolgens wordt getest welke subcompartimenten elkaar overlappen. Daarvan wordt een rapport gegeven (wat als dat erg lang is overigens kan worden geknipt & geplakt naar een tekstverwerker voor nader afdrukken of verdere bestudering). Tevens wordt bij alle compartimenten waarvan is opgegeven dat hun converteerbaarheid ‘automatisch bij conversie’ is, bij het kleinste subcompartiment van de twee overlappende ingevuld dat die niet moet worden meegenomen in de conversie van optie 8.1 hierboven.

Importeer PIAS compartimenten uit pre-2012 formaat

Met deze optie worden compartimenten ingelezen in het formaat van de voorloper van Layout, Compart (wat tot 2012 in gebruik is geweest voor het modelleren van compartimenten), en omgezet naar Layout compartimenten van het type ‘met coördinaten’. De gebruiker wordt geacht om die oude file aan te wijzen, de file extensie daarvan is .cmp.

Schoon pre-2012 PIAS compartimenten op

In het oude PIAS compartimentenmodule Compart konden subcompartimenten uitsluitend begrensd worden door acht hoekpunten. Daarnaast was er de eis dat ze convex moeten zijn, en in de test op convexheid mochten hoekpunten niet precies samenvallen. Dat leidde ertoe dat men voor bv. driezijdige of tapse compartimenten hoekpunten definieerde met verschilletjes van millimeters. Hier, in Layout, is dat niet meer nodig, sterker nog, die verschilletjes van millimeters werken contraproductief, want als Layout fysieke vlakken gaat construeren, dan wordt er daadwerkelijk een vlakje van een millimeter aangemaakt, en dat komt het overzicht niet ten goede. Met de onderhavige optie worden die verschillen opgespoord, en worden bijna samenvallende hoekpunten daadwerkelijk samengetrokken. Men moet zich trouwens wel realiseren dat deze optie niet alle anomaliën repareert, zodat er wellicht nog handmatige aanpassingen nodig zijn, bijvoorbeeld in het geval van:

• Grotere verschillen dan twee millimeter. Vanzelfsprekend zou het algoritme daar wel toe in staat zijn, maar het is maar de vraag in hoeverre een programma zelfstandig de door een gebruiker ingevoerde gegevens moet gaan veranderen.
• Een begrenzend vlak van een subcompartiment wat scheluw (niet zuiver vlak) is. Binnen een subcompartiment van het type ‘met coördinaten’ is daar geen bezwaar tegen, maar dit kan niet gebruikt worden om fysieke vlakken te genereren (die moeten immers volkomen vlak zijn).

Exporteer schotten en dekken naar Rapid Prototyping file (STL)

Met deze optie worden schotten en dekken geconverteerd naar STL formaat, wat geschikt is voor Rapid prototyping (ofwel 3D printing). Deze optie is nog experimenteel, en alleen beschikbaar voor SARC. Op www.sarc.nl/images/publications/appendix_swz2012.pdf staat een voorbeeld van hoe zo'n STL-bestand gebruikt kan worden om een scheepsindeling 3D te printen.

Exporteer naar Poseidon (DNV•GL)

Met deze optie worden gegevens uit PIAS geconverteerd, en weggeschreven in het formaat van Poseidon, het rules programma van DNV•GL. Het doel van deze conversie is om de gegevens zoals ze in PIAS beschikbaar zijn zo compleet mogelijk over te zetten naar Poseidon. De gecreëerde Poseidon file bevat de volgende gegevens:

• Hoofdafmetingen en andere algemene numerieke gegevens. Vergeet niet hiervoor de ‘bijkomende kenmerken’ ook in te vullen, zie Kenmerken voor export naar Poseidon. De minimum diepgangen achter en voor, die doorgegeven moeten worden aan Poseidon, worden afgeleid van de diepgangsmerken. Voor de zo compleet mogelijke Poseidon file zullen dus minstens twee diepgansmerken met een zg. ‘Tmax lokaal’ moeten worden opgegeven, zie daarvoor Diepgangsmerken en toegestane maximale en minimale diepgangen. Poseidon parameters waarvan geen gegevens in PIAS aanwezig zijn (zoals GL nummer en ijsklasse gegevens) worden leeg gelaten.
• Tabel van spantafstanden.
• De rompvorm, in de vorm van alle spanten die in het PIAS model aanwezig zijn.
• De vorm van langsschotten en dekken.
• De vorm van dwarsschotten, die in Poseidon als ‘transverse web plate’ worden gemodelleerd.
• Compartimenten.
• Globale belasting: de (omhullende van) de langsscheepse buigend momenten en dwarskrachten.
• Lokale belastingen: dekbelastingen, compartimentsvullingen en wielbelastingen.
• Langs- en dwarsdragers (girders and webs).
• Plaatindeling van huid, schotten en dekken (met een default plaatdikte).
• Langs- en dwarsverstijfers op huid, schotten en dekken.

Schip met dekken en vlakken uit PIAS, ingelezen en getoond in Poseidon.

Aanvullende Poseidon gegevens opgeven in Layout

Veel gegevens van geometrie van romp en indeling zijn al in Layout vastgelegd, en kunnen naar Poseidon worden geconverteerd zonder aanvullende handelingen. Poseidon heeft echter ook behoefte aan gegevens die helemaal niet in PIAS zitten, zoals lokale belastingen of constructiegegevens. Een aantal van die gegevens kunnen in Layout worden ingevoerd, in alfanumerieke invulmenus. Zodoende wordt met deze “Poseidon” export feature een tussenmenu geopend waarvan de eerste optie de daadwerkelijke export naar Poseidon uitvoert. De andere opties openen menus waarin specifieke Poseidon parameters, die ontbreken in PIAS, kunnen worden opgegeven. Sommige van deze parameters zijn helemaal des Poseidons, zodat voor hun betekenis en toepassing naar de handleiding van Poseidon wordt verwezen. Op de meer algemene zaken is de volgende toelichting van toepassing:

• T.b.v. Poseidon's “Cargo and Decks” kunnen in één van de invulmenu's de deklasten worden opgegeven. Daarbij moet men in eerste instantie een dek opgeven, waarvoor één van de fysieke vlakken van Layout wordt opgegeven d.m.v. zijn afkorting (men kan overigens elk soort vlak opgeven, ook een dwars- of langsschot, maar dat zou vrij zinloos zijn voor een deklast). De kern van de zaak is dat de deklast op dat dek geplaatst wordt. Aanvullend wordt een compartiment / subcompartiment combinatie opgegeven, die uitsluitend wordt gebruikt om de positie en lengte van de last aan te geven (er wordt overigens niet gecontroleerd of het dek inderdaad grenst aan het subcompartiment, dat moet men zelf in de gaten houden). Een uitzondering op dit mechanisme is een last op het bovendek. Daartoe geeft men de Poseidonterm “Tdeck” op als ‘afkorting’, benevens een compartiment / subcompartiment wat grenst aan de bovenkant van de romp. Dat dat subcompartiment onder dat dek zit i.p.v. erboven maakt niet uit, het dient immers alleen maar om de plaatsbepaling.
• Naast deklasten kunnen voor “Cargo and Decks” ook tankvullingen worden opgegeven, welke automatisch worden toegepast op het fysieke vlak wat aan de onderkant van een compartiment gelegen is. Een combinatie van tankvulling en deklast op hetzelfde dek is vanzelfsprekend niet denkbaar. Zou men dat toch opgeven dan prevaleert de deklast boven de tankvulling.
• Dwarsdragers (webs) kunnen worden opgegeven in groepen met per groep een achtergrens, voorgrens en de afstand tussen twee dragers. Voor elke dragergroep wordt een beginpunt en een eindpunt opgegeven. De orientatie (van binnen naar buiten of van boven naar onder) doet er niet toe. Het beginpunt en eindpunt liggen op de romp, of een Layout vlak, dat kan zowel een referentievlak als een fysiek vlak zijn. Deze vlakken geeft de gebruiker op d.m.v. z'n afkorting, dan wel de Poseidontermen “Tdeck” of “Shell” voor resp. dek of huid/vlak. Voor het begin- en eindpunt wordt opgegeven:
  1. Het Layout vlak waarop (=waarin) dit ligt, danwel huid/vlak/hoofddek, als het web daarlangs loopt. Dit noemen we vlak 1.
  2. De nadere positie van dit punt in vlak 1. In beginsel domweg een breedte- of hoogtemaat, maar om zoveel mogelijk het verband met de rest van de scheepsindeling te behouden wordt hier verwezen naar een ander vlak (danwel huid/vlak/hoofddek) — wat we vlak 2 noemen — zodat het begin/eindpunt wordt genomen op het snijpunt van de vlak 1 en vlak 2.
  3. De binnenkant van de drager, daarmee wordt dus de lijfhoogte op die plaats vastgelegd. Voor dit punt wordt een derde vlak (vlak 3) opgegeven, en de binnenkant van het web ligt dan op het snijpunt van vlak 2 en vlak 3. Aanvullend kan ook nog een offset t.o.v. vlak 3 opgegeven worden. Alternatief wordt er voor het web een constante lijfhoogte opgegeven, dan wordt vlak 3 weggelaten. Als het begin- en eindpunt hetzelfde ‘vlak 1’ hebben, en als dat een fysiek vlak is in Layout, dan zal bij een constante lijfhoogte de binnenkant meelopen met de buitenkant. Zo kan een web langs de huid opgegeven worden.
  Met deze parameters kunnen vrij gevarieerde constructieconcepten worden gedefinieerd, zoals geïllustreerd in Definitievoorbeelden van dwars- en langsdragers. Bij de dwarsdrager nog twee aan Poseidon gerelateerde details van belang:
  • Het is niet helemaal duidelijk hoe Poseidon bepaalt aan welke kant de lijfhoogte genomen wordt. Dat gebeurt soms aan de linkerkant van ‘vlak 1’, soms aan de rechterkant. Men zal dus zelf wat moeten experimenteren om daarin regelmaat te ontdekken.
  • Van een dwarsdrager kan worden opgegeven of deze zich aan BB, aan SB of aan beide zijden bevindt. Daar wordt in Poseidon op een losse manier gebruik van gemaakt, d.w.z. dat een dragervorm gewoon wordt gecopieerd naar de andere kant, ook zal zou het vlak waaraan de drager refereert aan die kant helemaal niet bestaan.
• Langsdragers (girders) worden in principe net zo opgegeven als dwarsdragers, alleen de terminologie verschilt hier en daar. Een groep van langsdragers kan worden opgegeven in breedterichting of in hoogterichting, dus niet in schuine richting. Breedtematen moeten uitsluitend positief opgegeven worden; met de schakelaar BB/SB/Dubbel kan de gewenste zijde aangegeven worden (zo werkt Poseidon nou eenmaal).
• Het opgeven van dragers in PIAS is erop gericht om snel — en geïntegreerd in de Layout schotten- en dekkenstructuur — de belangrijkste dragers en de meest voorkomende dragerconfiguraties op te geven. Niet elke dragervariant of -detail wordt echter door het PIAS mechanisme ondersteund.
• Verstijvers op web platen zijn gemakkelijk gedefinieerd door het opgegeven van de afkorting van een Layout vlak of Poseidon element “Tdeck” of “Shell”. Definieer nu het start en eind punt van de verstijver's gemalde lijn en de hart tot hart afstand en het aantal verstijvers. De laatste dingen die nog moeten worden gedefinieerd zijn; op welke zijde de verstijver gepositioneerd moet worden en het definieren van het type en de afmetingen van de verstijver en hoe de verstijver is gepositioneerd ten opzichte van zijn gemalde lijn.
• Dwars en langs verstijvers op langs platen worden gedefinieerd op een gelijke wijze als verstijvers op web platen. Er zijn twee toevoegingen, namelijk;
  • Voor dwars en langs verstijvers op langs platen moet men een langsscheeps start en eind punt definieren. In plaats van één begin en eind punt voor de verstijver's gemalde lijn zijn er nu twee, één op het langsscheepse begin en één op het langsscheepse eind punt. Het begin en eind punt van de verstijver zijn gemalde lijn worden geinterpoleerd in relatie tot het element waarop deze verstijver is gepositioneerd, dekken en langsscheepse schotten hebben een vaste interpolatie richting, maar de Poseidon elementen “Tdeck” en “Shell” kunnen zowel verticaal of horizontaal worden ingesteld.
  • Voor de langsscheepse verstijvers op langsscheepse platen geldt nog een extra optie, namelijk het definieren van de rotatie van de verstijver ten opzichte van zijn gemalde lijn. Tevens kan deze rotatie ook nog relatief worden gemaakt ten opzichte van de plaat waarop de verstijver is gepositioneerd.
• Het definieren van plaatvelden is gerealiseerd door middel van het opgeven van de afkorting van een Layout vlak of van Poseidon element “Tdeck” of “Shell”. Vervolgens dient de ‘standaard plaat’ afmeting en de gemalde lijn van het Layout vlak of danwel Poseidon element gedefinieerd te worden. De fysieke oppervlakte van het Layout vlak of Poseidon element zullen worden opgedeeld in een aantal plaatvelden met de eerder genoemde standaard plaat afmeting. Deze deling wordt op een specifieke manier verwerkt voor elk element:
  • Langsscheeps, van achteren naar voren; Dwarsscheeps, van hartlijn naar buiten; Verticaal, van de bodem tot het hoogste punt.
  • De specifieke Poseidon elementen “Tdeck” en “Shell” worden op dezelfde manier verwerkt als de Layout vlakken, maar de specifieke geometrische definitie van deze elementen is buiten PIAS's controle.

Definitie gemalde lijn vlak en verstijver.

Definitievoorbeelden van dwars- en langsdragers

Voorbeeld 1: Er zijn altijd twee intrinsieke vlakken aanwezig, nl. huid/dek en hoofddek. En laten we voor het gemak ook ‘hartschip’ (HS) maar intrinsiek maken. Het web met vaste hoogte H, zie onderstaande afbeelding, wordt dan gedefinieerd door:

• Beginpunt vlak ‘Huid/dek’, op snijpunt met HS.
• Eindpunt ook vlak ‘Huid/dek’ (dat moet wel, omdat we een constante lijfhoogte gebruiken), op snijpunt ‘hoofddek’.
• Constante lijfhoogte H.

Definitie dwars- en langsdragers, voorbeeld 1.

Voorbeeld 2: Webplaten A en B worden apart gedefinieerd, zie onderstaande afbeelding. Eerst plaat A:

• Beginpunt langs vlak huid/dek, op snijpunt met HS.
• Bij dat beginpunt de binnenkant van dat web op hoogte TT. Hiervoor wordt het snijpunt van HS en TT genomen, en dat is precies de bedoeling.
• Het eindpunt vlak huid/dek, op het snijpunt met TT.
• Bij dat eindpunt de binnenkant van dat web op hoogte TT. Hiervoor wordt het snijpunt van TT en TT genomen, en dat zijn er oneindig veel, maar wij kiezen in dat uitzonderingsgeval het snijpunt van huid/dek en TT, en dat is de bedoeling.

En plaat B:

• Beginpunt langs vlak huid/dek, op snijpunt met TT.
• Bij dat beginpunt de binnenkant van dat web op breedte R1. Hiervoor wordt het snijpunt van TT en R1 genomen, en dat is precies de bedoeling.
• Eindpunt langs vlak huid/dek, op snijpunt met hoofddek.
• Bij dat eindpunt de binnenkant van dat web op breedte R1. Hiervoor wordt het snijpunt van hoofddek en R1 genomen, en ook dat is precies de bedoeling.

Definitie dwars- en langsdragers, voorbeeld 2.

Voorbeeld 3: Tenslotte onderstaande afgebeelde constructie, met een dek en een langsschot, die allebei van twee dragers voorzien zijn van verschillende afmetingen. Er zijn vier webs, web A is als volgt vastgelegd:

• Beginpunt langs vlak TD, op snijpunt met HS.
• Eindpunt langs vlak TD, op snijpunt met LS0 of LS1.
• Constante lijfhoogte wat hoort bij A.

Deel B:

• Beginpunt langs vlak TD, op snijpunt met LS0 of LS1.
• Eindpunt langs vlak TD, op snijpunt met huid/vlak.
• Constante lijfhoogte wat hoort bij B.

Deel C:

• Beginpunt langs vlak LS0, op snijpunt met huid/vlak.
• Eindpunt langs vlak LS0, op snijpunt met TD.
• Constante lijfhoogte wat hoort bij C.

Deel D:

• Beginpunt langs vlak LS1, op snijpunt met TD.
• Bij dat beginpunt de binnenkant van dat web (ook) langs vlak LS1, op snijpunt met TD, met offset HD0.
• Eindpunt langs vlak LS1, op snijpunt met hoofddek.
• Bij dat eindpunt de binnenkant van dat web (ook) langs vlak LS1, op snijpunt met hoofddek, met offset HD1.

Merk op dat de delen A en C gedeeltelijk overlappen. Dat is niet anders, dit is een ontwerpmodel waarbij niet elk detail tot in de finesses is weergegevn. Ten bate van de eenvoud van de gegevensdefinitie (en dus de definitiesnelheid).

Zoals eerder besproken kan één web zich ook uitstrekken langs meerdere vlakken. Stel dat C&D een constante lijfhoogte H hebben (en constante dikte en zo) dan kan dat als volgt worden opgegeven:

• Beginpunt langs vlak LS0, op snijpunt met huid/vlak.
• Eindpunt langs vlak LS1, op snijpunt met hoofddek.
• Lijfhoogte H.

Definitie dwars- en langsdragers, voorbeeld 3.

Tenslotte nog een toelichting op het begrip ‘Newlay-vlak’. Zo'n vlak wordt gebruikt t.b.v. de vastlegging van de posities van de webs, meer is het niet. Er worden verder dus geen eisen gesteld aan aanwezigheid of continuiteit van vlakken. Dat geeft een zekere vrijheid, zo kan gebruikt worden:

• Een referentievlak. Dat is makkelijk, die strekken zich altijd over het hele schip uit.
• Een fysiek vlak, wat sowieso gebruikt kan worden waar het zich werkelijk bevindt.
• Een doorgetrokken fysiek vlak. Uiteindelijk is een fysiek vlak niks anders dan een oneindig vlak plus een zekere gesloten begrenzing daarop. Ook buiten die begrenzing loopt dat oneindige vlak gewoon door, en daar kan qua maat best gebruik van gemaakt worden. Zo kan bijvoorbeeld voor de hoogte van een vrang worden gerefereerd aan de tanktop, zelfs in delen waar die tanktop niet aanwezig is.

Werkwijze van de PIAS naar Poseidon conversie

1. Gebruik deze Layout optie, waarmee een tekstbestand wordt aangemaakt met extensie .txt (zoals vereist voor de import in Poseidon).
2. Start Poseidon, en doe File/Open.
3. Kies bij Files of type: Poseidon TXT File (*.txt).
4. Wijs het zojuist door Layout aangemaakte bestand aan.

Schip, indeling, huidplaten, dragers, web platen en verstijvers vastgelegd in PIAS, geconverteerd naar Poseidon.

Ontwerpuitgangspunten, beperkingen en voorwaarden

De PIAS→Poseidon conversie is, in samenwerking met de eerste afnemer, ontworpen met het volgende gebruik voor ogen:

1. Scheeps- en indelingsgegevens die intrinsiek in PIAS aanwezig zijn moeten naar Poseidon geconverteerd kunnen worden.
2. Het is de bedoeling van die afnemer om uiteindelijk veel scheeps-, indelings- en constructiegegevens te beheren vanuit een centrale ontwerpsysteem, en die o.a. via PIAS naar Poseidon te converteren.
3. Op praktische gronden is ervoor gekozen om gegevens die in oorsprong niet in PIAS zijn opgenomen (zoals dekbelastingen, dragers en verstijvers) voorlopig in PIAS in simpele alfanumerieke menutjes in te voeren. Deze invoermenus verliezen hun rol als deze gegevens in het centrale ontwerpsysteem zijn opgenomen. Vandaar dat deze invoermenus nogal Spartaans zijn, en niet zijn voorzien van grafische controle- of invoerfaciliteiten.
4. PIAS hanteert voor deze aanvullende gegevens t.b.v. Poseidon een opslag in XML formaat. Dat biedt dat centrale ontwerpsysteem de mogelijkheid om dezelfde gegevens ook in dat formaat weg te schrijven, zodat ze direct in PIAS beschikbaar zijn (en dus voor conversie naar Poseidon).
5. De gegevens die PIAS aan Poseidon aan kan leveren is met de huidige implementatie voldoende voor die eerste afnemer. Er zijn echter ook zaken die niet in PIAS en deze conversie zitten, zoals stutten, mangaten en lasdetails. Het is vooralsnog niet de bedoeling de conversie met deze onderdelen uit te breiden, hoewel in concrete gevallen met concrete gebruikers natuurlijk altijd over uitbreiding gesproken kan worden.
6. Het staat iedere gebruiker natuurlijk vrij om aanvullend op de gegevens die uit PIAS geïmporteerd worden, met de User Interface van Poseidon onderdelen aan te vullen of te wijzigen.

Attentie

Het interface formaat van Poseidon kent soms hele specifieke vereisten en beperkingen. In deze conversieoptie van PIAS is veel moeite gestopt om daaraan zoveel mogelijk tegemoet te komen, en bij het vele testen is gebleken dat de geometrie uit PIAS goed in Poseidon binnenkomt. In het algemeen wordt een vlekkeloze werking in Poseidon echter niet gegarandeerd.

Op deze conversie zijn de volgende opmerkingen en voorwaarden van toepassing:

• Deze conversie is getest met en geldig voor Poseidon versie 17.0.8, (2018).
• Poseidon is helemaal geënt op bouwspanten, dus het is van het grootste belang om de bouwspantafstanden in PIAS accuraat op te geven (zie Spantafstanden), inclusief de plaats van het eerste en het laatste spant.
• Schuin staande dwarsschotten zijn uitgezonderd van deze conversie.
• Voor Poseidon is het een vereiste dat spant 0 samenvalt met de ALL (zie hoofdstuk 2.2 van de Fundamentals handleiding van Poseidon).

In Poseidon kan een zg. longitudinal element worden begrensd door hetzij een ander element, hetzij de huid. Maar in werkelijkheid kan dat soms verspringen, bv. de ondergrens van een langsschot kan aan de achterkant de tanktop zijn, en aan de voorkant de huid. T.b.v. Poseidon moet dat langsschot dus opgesplitst worden in twee delen; 1x het achterste deel wat door de tanktop begrensd wordt, en 1x het voorste deel met de huid als begrenzing. Dat opsplitsen doet PIAS automatisch, maar er is helaas wel een valkuil, en die is gerelateerd aan de exacte plaats van het splitsingspunt, wat precies op het snijpunt van twee interne vlakken en de huid moet liggen. In ons voorbeeld op het snijpunt van langsschot, tanktop en huid. Nu is dat punt d.m.v. interpolatie best te bepalen, maar aangezien PIAS en Poseidon hun eigen onafhankelijke interpolatiemethodes gebruiken kan het best eens voorkomen dat op de plaats waar volgens PIAS de splitsing ligt, er volgens Poseidon nou net geen verbinding tussen langsschot en tanktop meer is. In zo'n geval zal de splitsingsplaats in Poseidon handmatig een beetje moeten worden aangepast. Dit verschijnsel is intrinsiek aan werkwijze van Poseidon, met name aan het vereiste dat zo'n longitudinal element gesplitst moet worden, en kan in principe niet voorkomen worden. In de praktijk zal het echter minder vaak voorkomen naarmate er minder geïnterpoleerd wordt, dus is het aan te raden om zoveel mogelijk spanten (bij voorkeur alle bouwspanten) in PIAS op te nemen (die bv. bij het gebruik van Fairway heel makkelijk te genereren zijn).

Schrijf XML bestand

Met het oog op communicatie met andere software kan men met deze optie de scheepsindelingsgegevens exporteren in een XML-bestand. Op dit moment bevat zo'n bestand gegevens van compartimentsvormen, schotten & dekken en referentievlakken. Deze gegevensverzameling is beperkt tot dat wat gebruikers tot nu toe nodig hebben gehad, en bevat bv. wel vormen, namen en plaatsen van de entiteiten, maar niet alle details. Bv. de tweede compartimentsnaam en de peilpijp ontbreken nog. Naar behoefte kunnen deze zaken echter worden toegevoegd, zie ook Export naar en import uit XML. De bestandsnaam van de file die geschreven wordt is PIASfilenaam.fromLayout.XML.

Overigens is deze XML gegevensuitwisseling niet alleen beschikbaar is een file, maar ook in directe en permanente communicatie tussen computerprogramma's. Op die manier kan met verschillende CAD programma's gelijktijdige gewerkt worden aan hetzelfde scheepsontwerp. Meer details hierover zijn te vinden in het paper www.sarc.nl/images/pdf/publications/international/2015/Koelman%20Compit%202015.pdf wat gepresenteerd is op het Compit'15 congres.

Lees XML bestand

Met deze functie kan een XML bestand met scheepsindeling worden ingelezen in Layout. Alle opmerkingen die gemaakt zijn in de vorige paragraaf, over het exporteren, zijn hier ook van toepassing. De bestandsnaam die verwacht wordt is PIASfilenaam.toLayout.XML.

Als een file wordt ingelezen die wel vlakken heeft, maar niet (overal) compartimenten dan zullen er dus ruimtes tussen die vlakken ontstaan die niet met een compartiment ingevuld zijn. Het zou handig kunnen zijn om Layout dan zulke compartimenten te laten genereren. Daarom stelt het programma de vraag ‘Wat te doen met loze ruimtes tussen vlakken?’, waarop men dan een gepast antwoord dient te geven.