INPI-France/Brevets-Francais-2024-Chunked huggingface dataset:
Notre expérience dans le suivi de l'état de la matière nous a conduits à nous poser constamment une clé de variation de cet état qui peut être résumé par AS la variation d'entropie. En effet,en se reportant aux tableaux que nous avons déja présentés, on s'aperçoit qu'il y a de très fortes corrélations entre S et les paramètres physiques de fusion et d'ébullition et plus généralement de changements d'état ou d'organisation de la matière.
//Définition of one Process entry into the process list typedef struct int pid ; // process unique identifier int ppid ; // fâcher process identifier int jobid; // unique identifier of the job int HandleTablelndex; // index in the table of handle on started process union ( int iUseCount; // number of referency on this process entry int iTotalEntryCount; // number of entry in lise (HEADER entry #0) }; BOOL IsActive; // che process is active or not BOOL IsSaved; // TRUE after saving into accounting file int index~father; // pointer/index on father process entry in list union ( int index~brother; // pointer/index on brother process entry in list int iList~NextFree;// pointer/index on free entry of the list (HEADER entry #0) // free entry are chained with NextFree pointer ); union ( int index~child; // pointer/index on child lise entry in lise // -1 when the entry is into the free list int iList~UsedEntry;// pointer/index on child list entry in list (HEADER entry #0) // le is the list of active process } ; STRUCT~FIFO myProcessData; // information of the process >LiscProcess, *PLisCProcess; typedef struct ~OneFifoEntry ( DWORD dwProcessId; // process identificator DWORD dwParentProcessId; // parent identificator, -1 if unknown union( LARGE~INTEGER CreateTime; // create date ~int64 iCreateTime; } ; union( FILETIME ExitTime;// exit date with some micro seconds of error ~int64 iExitTime; LARGE~INTEGER liExitTime; } ; union( LARGE~INTEGER KernelTime; // Kernel time at exit time ~int64 iKernelTime ; ); union( LARGE~INTEGER UserTime ; // User time at exit time ~int64 lUserTime; ); ULONG Peak'rlorkingSetSize; // Max usage of working set ULONG PeakPagefileUsage; // Max usage of page file ULONG ReadOperationCount; // Read disk operation ULONG WriteOperationCount; // Write disk operation ULONG ExicCode; // 'Unused' exit code of the process CHAR CommandLine[MaxCmdLine]; // first char of the command line ) STRUCT~FIFO, 'PSTRUCT~FIFO;
while (iSaveListCount> 0) F-nterCriticalSection(&gCS~ProtectSavingBuffer); // Get one entry CopyOfProcess a TheSaveListtiSaveListNextGeti; iSaveListNextGet++; if (iSaveListNextGet > MaxProcessList) iSaveListNextGet=0; iSaveListCount--; LeaveCriticalSection(&gCS~ProtectSavingBuffer); // Save entry into accounting file outside lock scrnepy(work-acct-command, CopyOfProcess.myProcessData.CommandLine, sizeof work acct.command) -1); work~acct.jobid = (unsigned char)Copy0f?rocess.]obid; wark-accu.startti-ne = (time~t)ConvertFileTimeToINT(CopyOfProcess.myProcessData.iCreateTime); work~acct.endtime = (t.me~t)ConvertF-leT4-MeTol.,JT ( Copy0f?rocess.myProcessData.ixitTimel; work accc.usercpu = (unsigned long) { ( incS4 ) CopyOfProcess .myProcessDaca. iUserTime/ (~int64)100000); work acc syseemcpu = (unsigned long)((-int64) CopyOfProcess.myProcessData.iKernelTime / ( inc64 ) 100000) ; work-accc.nbiochars - CopyOfProcess.myProcessData.ReadOperationCount CopyOfProcess.myProcessData.WriteOperationCount; work~accc .maxmemoryusage CopyOfProcess .myProcessDaca. PeakWorkingSecSize; work~acec.maxpagef!.le - = CopyOfProcess.myProcessData.PeakPagefileUsage; work~acct.processPid = CopyOfProcess .pid; work~accc.processPPid CopyOfProcess.ppid; if (CopyOfProcess.myProcessData.ExitCode -5) ReadExitCodeAndDeleteHandle(CopyOfProcess.HandleTableIndex,FALSE); work~acct.exit~status = CopyOfProcess.myProcessData.ExitCode; ) else work~acct.exit~status = ReadExitCodeAndDeleteHandle( CopyOProcess.HandleTableIndex,TRUE); ) DWORD dwWritten; if (writeFile(hFileAccounting,&work~accc,sizeof(scrucz acct),&dwWritten,NULL) !=TRUE) TraceMessage(TEXT('Error during accounting WRITE operation..\n )); if (dwwritten != sizeof(struct acct)) TraceMessage(TEXT( Error : imcomplete accounting WRITE operatlon..\nO)); )
exemple 1 de résultat : historique
Command Job Start End Elapse User Syat MaxMem MaxPag Exit Statua C:\NuTC\MKSNT\sh.exe --432 "Oct 7 1996 14:40:00' 255 13:40:38 13:40:38 0. 00 0. 02 0. 02 1392640 561152 pstat 255 13:40:38 13:40:48 10. 00 0. 06 0. 07 1019904 364544 C:\NuTC\MKSNT\sh.exe --372 "Oct 7 1996 14:40:00" 255 13:40:37 13:40:48 11. 00 0. 03 0. 03 1392640 557056 C:\NuTC\MKSNT\sh.exe -- 264 "Oct 7 1996 14:40:00" 255 13:40:37 13:40:48 11. 00 0. 03 0. 06 1548288 544768 C:\NuTC\MKSNT\sh.exe -- 260 "Oct 7 1996 14:40:00" 255 13:40:37 13:40:48 11.00 0. 03 0. 03 1515520 544768 grep discoveryd 255 13:40:37 13:40:48 11. 00 0. 02 0. 01 864256 253952 Exit 1 C:\NuTC\MKSNT\sh.exe -- 244 "Oct 7 1996 14:40:00" 255 13:40:37 13:40:48 11. 00 0. 01 0. 07 1396736 557056 Exit : 1
awk "/vi/{next)/start~disco/{next)/grep/{next)~" 255 13:40:37 13:40:48 11.00 0.01 0.00 925696 299008 C:\NuTC\MKSNT\sh.exe -- 444 "Oct 7 1996 14:40:00" 255 13:40:37 13:40:48 11.00 0.03 0.04 1396736 557056 C:\PROGRA-I\Vision\Sys\xvl.exe -profile "XVision" 255 13:40:44 13:41:58 74.00 0.05 0.17 2936832 1224704 Exit : 1
"C:\PROGRA-1\Vision\xvision.exe" 255 13:40:40 13:42:03 83. 00 0. 03 0. 03 1585152 417792 Exit : 1 ism-daemon -profile OAM/oamcs.sml 255 13:40:34 13:42:06 92. 00 0. 28 0. 33 6410240 4595712 Exit : 1 conso -c 1 -t 10-m 42 255 18:25:04 18:25:15 11.00 0. 97 0. 32 45404160 44519424 conso-c 1 -t 10-m 20 255 18:25:06 18:25:17 11. 00 0. 95 0. 34 22286336 21426176 exemple 2 edition de l'arbre binaire avec la structure et les paramètre de fonctionnement des processus @ XIII Accounting process list is : r ---pid=232, J=-l(l) testaccounting edit ~pid=207, J=-l(l) f :\ism\bin\cdspsprv.exe ~pid=175, J=-1(1) sh. exe F:/ISM//bin/start~ismConfig.ksh -0 -om ismConfig -archive /var/db/ISM-Configurator/configBase ~pid=337, J=-l(l) F:\ISM\bin\ods~light -daemon -profile F:\ISM/Sml/ISM-Configurator/ods~config.sml -host HANIN-arch ~pid=357, J=-1 (1) sh.exe F:/ISM//bin/is-miss.ksh -iso -pid=274, J=-l(l) elm 0 ~pid=119, J=-l(l) /F=/ISM/bin/evlog-d 0 0 /F=/ISM/var/db/elm/elmO/alarms "" ~pid=197, J=-l(l) sh. exe F:/ISM//bin/ism-ods.ksh -0 ~pid=222, J=-1(1) C :\NuTC\MKSNT\sh.exe -- 212 "Oct 7 1996 14:40:00pid=240, J=-l(l) sh. exe F:/ISM//bin/start~inv.ksh -0 -om ism-invenCory ~pid-455, J=-l(l) C :\NuTC\MKSNT\sh.exe -- 412 "Oct 7 1996 14:40:00' id=191, J=-l(0) sh.exe F:/ISM//bin/start ep.ksh ~pid=373, J=-l(0) F:\ISM\bin\ism~ep -daemon ~pid=388, J=-l(l) F:\ISM\bin\ism~ep -daemon ~pid=368, J=-1 (1) C:\WINNT\system32\nutcserv.exe 373 ~pid=224, J=-l(l) air -fAlarmLog -nalr. stdout -oalr -malm pid=405, J=-l(l) sh.exe F:/ISM//bin/start tmn~ep.ksh -mibname TMNep ~pid=257, J=-l(l) F:\ISM\bin\tmn~ep -daemon-mibname TMNep ~pid=347, J=-1(1) F:\ISM\bin\tmn~ep -daemon -mibname TMNep ~pid=347, J=-l(l) C:\WINNT\system32\nutcserv.exe 257 ~pid=438, J=-l(l) alw -fAlarmLog -nalw.stdout -oalw -malm niti=7R..T=-1 Il1 1 crî.n ova
AMPLIFICATEUR OPTIQUE DE PUISSANCE À GUIDE D'ONDE PLANAIRE POMPÉ OPTIQUEMENT ET LASER DE PUISSANCE UTILISANT CET AMPLIFICATEUR DESCRIPTION DOMAINE TECHNIQUE La présente invention concerne un amplificateur optique de puissance à guide d'onde planaire pompé optiquement ainsi qu'un laser de puissance utilisant cet amplificateur.
L'invention trouve des applications notamment dans les domaines suivants : marquage et micro-marquage par laser, télémétrie à longue distance, télécommunications, en particulier télécommunications spatiales (entre satellites), affichage par laser, instrumentation scientifique et instrumentation biomédicale.
L'invention est avantageusement utilisable dans une structure de type amplificateur de puissance à oscillateur maître ( master oscillator power amplifier ) plus simplement appelée MOPA.
Cette structure utilise une source laser (oscillateur maître) de faible puissance, capable d'émettre un faisceau laser de grande qualité optique, ainsi qu'un amplificateur optique de puissance qui est susceptible d'apporter la puissance nécessaire à l'amplification de ce faisceau, tout en détériorant le moins possible les qualités originelles de celui-ci.
Dans l'amplificateur optique, un milieu laser, dopé avec des ions optiquement actifs, est pompé
optiquement par exemple par des diodes lasers de puissance pour amplifier le faisceau laser incident. Il s'agit d'un amplificateur à onde progressive ( travelling wave amplifier ) plus simplement appelé TWA. En effet l' amplification est réalisée au cours de la traversée, par le faisceau laser, du milieu laser amplificateur.
Un tel amplificateur optique n'est donc pas un laser (qui comprend toujours une cavité résonante) et il faut même éviter le plus possible qu'un tel amplificateur devienne un laser pour avoir un meilleur gain.
ÉTAT DE LA TECHNIQUE ANTÉRIEURE On connaît des amplificateurs optiques massifs ( bulk ) en forme de barreau ( rod ) ou en forme de plaque ( slab ). Ces amplificateurs optiques peuvent amplifier une forte puissance mais avec un faible gain. De plus leurs longueurs sont de l'ordre de plusieurs centimètres voire plusieurs dizaines de centimètres. Ils ne sont donc pas compacts.
De tels amplificateurs sont par exemple considérés dans le document [4] qui, comme les autres documents cités par la suite, est mentionné à la fin de la présente description.
On connaît aussi des amplificateurs optiques en forme de plaque mince ( thin slab ). Cependant ces amplificateurs ne permettent pas de guider un faisceau laser-incident de façon monomode de sorte que la qualité du faisceau de sortie est médiocre. Il en résulte par exemple que la focalisation d'un tel faisceau de sortie sur une très petite surface
L'exemple 9 montre que la composante A peut être obtenue par génération in-situ du sel simple de nickel grâce à l'action du chlorure d'hydrogène sur le métal massif en poudre. Les exemples 10 et 1 1 illustrent le fait que l'auxiliaire de solubilisation peut être un autre halogénure soluble ou q
Etat de la technique
L'invention concerne un phare pour véhicules se-
lon le principe de projection qui comprend un réflecteur, une source de lumière, une lentille, à travers laquelle passe la lumière qui est réfléchie par le réflecteur, et un élément
qui laisse passer au moins en partie la lumière et qui en-
toure la lentille sur au moins une partie de son pourtour, élément à travers lequel passe et se concentre la lumière
émise par la source de lumière, et qui ne peut pas être cap-
tée par le réflecteur; la lumière réfléchie par le réflec-
teur et qui passe à travers la lentille, présentant une
limite supérieure de clair - obscur.
On connaît un tel phare par le document DE 32 18 703 Ai. Ce phare présente un réflecteur, une source de lumière et une lentille à travers laquelle passe la lumière réfléchie par le réflecteur. En outre le phare présente un élément qui laisse passer la lumière entourant la lentille au
moins sur une partie de son pourtour, élément à travers le-
quel peut passer et se concentrer la lumière émise par la
source de lumière qui n'est pas saisissable par le réflec-
teur. L'élément présente pour cela des prismes provoquant une déviation de la lumière passant à travers. Au moyen de cette configuration de l'élément, la surface d'éclairage du phare est agrandie par rapport à la surface de la lentille quand la source de lumière est allumée, de telle sorte que le phare ne
cause pas d'éblouissement ou ne cause qu'un faible éblouisse-
En gros, disons que le poids des molécules est divisé par 2 à chaque passage dans l'injecteur ,avec un taux de conversion de ( 1-1/e = 0.63 ).
Ce processus change donc très peu le rapport H/C des produits.
13 / Le Contrôle de la rupture des molécules permet d'éviter de produire des gaz ,d'une part en ne mettant jamais en oeuvre l'énergie requise à leur formation et d'autre part en choisisant les conditions de mise à l'équilibre dans le réacteur défavorable à leur apparition.
14 / Les Produits utiles peuvent être ; - soit hydratés et composés par l'émulsion mentionnée en 11 - soit anhydres et obtenus par une déshydratation extractive.
Aucun des processus ci-dessus n'est critique en lui-même et peut être rattrapé par les autres au détriment d'une baisse de performances, des taux de conversion ,d'une consommation d'énergie supérieure ou d'une production supérieure de Carbone Solide.
Selon une autre série de particularités de notre invention ,une grande attention est apportée aux contraintes de la matière en cours de traitement.
Bien que ceci ne soit qu'une tentative d'explication très grossière et imparfaite , on peut imaginer que la chaleur dans son aspect thermique est emmagasinée sous forme de vibrations mécaniques des molécules.
Les vibrations engendrent des contraintes mécaniques qui ,en raison de l'inertie liée à la masse , sont maximales au milieu de la molécule,si les vibrations sont modérées. Ces contraintes conduisent alors à une rupture au milieu de la molécule.
Plus on chauffe la molécule (ou plus généralement, plus on lui fait stocker de l'énergie de quelque nature que ce soit),plus elle va vibrer.Pour cela elle va vibrer sur des modes harmoniques ayant plusieurs ventres et creux de vibration comme chacun a pu l'observer sur une corde de piano ou la drisse d'un drapeau flottant dans un vent très fort ,ou encore sur une longue verge que l'on agite. Les creux de vibration étant le siège des contraintes maximales la molécule va se casser à ces points là, au tiers ,au quart,etc.. de sa longueur.
Ceci donne une image qui explique que si on chauffe trop (si on transmet trop d'énergie ) à une molécule elle va se fragmenter en tout petits morceaux qui s'arrêtent au CH4 et même au Carbone C.
Avec cette explication sommaire ,on peut encore comprendre que plus une molécule est longue donc massive et lourde plus elle a des éléments vibrants, plus les éléments centraux retemant les nombreux éléments latéraux qui s'agitent doivent forcer pour les retenir.
S'ils forcent trop ,ils craquent .
Cette image permet d'expliquer que plus la molécule est lourde moins elle supporte la chaleur sans craquer.
Pour fixer les idées le CH4 supporte mal des températures de plus de 700 C
et les Résidus lourds, des températures de plus de 430 C.
Dans le choix des dispositifs, ces contraintes se traduisent encore par les Flux de chaleur maximaux admissibles exprimés en Kcal/heure/mètre carré ,ou encore par les Différences de température admissibles entre la paroi chaude et le fluide froid.
- l'administrateur (41) peut modifier les attributs d'un objet MIB (l'opération M-SET). L'agent modifie l'équipement "réel" en fonction des nouvelles valeurs d'attributs fournies par l'administrateur;
- l'administrateur (41) peut exécuter une action sur un objet MIB par l'opération M-ACTION. L'agent (43) exécute une action sur l'équipement en fonction de l'action demandée par l'administrateur sur l'objet abstrait ; - l'administrateur (41) peut créer et supprimer des objets de la MIB par les opérations M-CREATE et M-DELETE; - l'agent (43) peut notifier un événement survenant sur un objet de la MIB à l'administrateur par l'opération M-EVENT. L'agent envoie des informations d'un événement concernant un objet abstrait pour décrire un événement survenu sur un équipement "réel".
Une base d'information d'administration (MIB) a une hiérarchie d'arborescence stricte, c'est-à-dire que chaque instance d'objet (MOI) a exactement une et une seule MOI supérieure. L'arbre formé par la base d'information d'administration MIB est appelé "arbre de contenance" (containment tree). Les instances d'objets administrés (MOIS) sont nommées par leur position dans l'arbre de contenance de la façon suivante: Chaque MOI possède un nom distinctif relatif (relative distinguished name, RDN) qui différencie les MOIs ayant un même et unique MOI supérieur (père). Un des attributs de chaque classe d'objets administrés (MOC) est choisi pour spécifier le RDN de l'instance pour un MOI supérieur donné. Cet attribut appelé l'attribut de nommage (naming attribute) est identifié dans les formulaires (templates) GDMO appelés liens de nommage (name binding). Une MOC peut avoir plusieurs liens de nommage supérieurs potentiels, mais chaque MOI utilisera uniquement l'un d'entre eux. Chaque MOI a également un nom distinctif complet (Full Distinguished Name) unique pour la totalité de la MIB. Le nom distinctif global (DN) d'un objet consiste en son nom distinctif relatif (RDN) joint au nom distinctif (DN) de son supérieur c'est-à-dire que le nom distinctif (DN) d'une instance d'objets administrés (MOI) contient son propre nom distinctif relatif (RDN) plus les noms distinctifs relatifs (RDNs) de tous ses supérieurs dans l'arbre de contenance jusqu'à la racine.
Un des administrateurs d'objet local à l'administrateur ISM-Manager s'appelle CMIS-DB. Il est chargé de stocker une partie de la MIB locale. La rémanence de ces objets stockés est assurée par des fichiers ISAM (Index Sequential Access Method). Cette technologie (ISAM) qui décrit les structures d'articles (records) est une méthode d'accès aux fichiers structurés sous forme d'articles découpés sur un ou plusieurs index et des informations de donnée.
Lorsque l'application de l'administrateur veut sélectionner un des objets pour poser une opération CMIS comme par exemple un M-GET, il doit spécifier l'instance d'objet de base (BOI, Base Object Instance), la portée (scope) et le "filtre" comme argument de l'opération .
L'instance d'objet de base BOI permet d'identifier un objet dans une base d'information d'administration (MIB) qui est le point de départ d'une évaluation du couple portée-filtre dans l'arbre d'objets. La portée (scope) sélectionne une portion de l'arbre depuis cet objet de base. Par exemple, la portée (scope) tous les sous arbres ( Whole subtree ) permet de sélectionner tous les sous arbres d'un objet donné. Parmi tous les objets de la portée (scope), les objets sélectionnés sont ceux pour lesquels l'évaluation du filtre est vraie. L'opération est effectuée sur les objets réellement sélectionnés. L'administrateur envoie un M-GET sur des objets et CMIS-DB lit et retourne à l'application la valeur des attributs des objets sélectionnés.
Pour atteindre une instance d'objet de base (BOI), l'administrateur local CMIS-DB doit passer d'objet père en objet fils jusqu'à atteindre le noeud de l'objet de base. Cette opération de navigation peut être longue, si pour passer d'un noeud à l'autre, il faut lire physiquement l'ensemble des fils d'un noeud et parmi ceux-là choisir celui qui a le bon RDN, et ainsi de suite.
Une fois, que l'ordinateur a atteint l'instance de base objet, il doit lire les attributs des objets de la base qui correspondent à la portée (scope) pour
pouvoir évaluer le filtre en mémoire, alors que la lecture des instances se fait sur le disque de la machine.
Un but de la présente invention est de proposer un procédé d'optimisation des lectures dans une base d'information d'administration (MIB) organisée en arbres d'instances d'objets de classes diverses, de l'ensemble des instances d'une classe donnée existantes dans cette MIB.
De plus le procédé selon l'invention fourni par le processus CMIS- DB de l'entité ISM-Manager permet d'appliquer une sélection par les arguments portée/filtre (scope/filter) des opérations standard du service CMIS pour offrir l'avantage de sélectionner ces objets de classe donnée à travers une seule opération. Sans cette invention la seule portée (scope) CMIS qui pourrait atteindre en une seule opération CMIS ces instances d'objets, est une portée (scope) de type (whole-subtree) tout le sous- arbre à partir de la racine de la MIB globale, hors celle-ci contient également des sous-arbres qui n'appartiennent pas à l'administrateur local CMIS-DB. L'autre alternative est de soumettre autant d'opérations CMIS qu'il y a d'objet MOI racine de sous-arbres (rootlet) stockés dans l'administrateur local CMIS-DB avec une portée (scope) de type tout le sous-arbre (whole- subtree) et une baseObjectlnstance égale à chacune de ces rootlets.
L'idée de l'invention est de représenter l'ensemble des instances, d'une classe donnée d'objets administrés MOC, existante dans le service commun de gestion d'informations (CMIS-DB) par un objet de classe spécifique appelée mocExtension géré automatiquement par le service commun de gestion d'informations CMIS-DB pour être la racine d'une copie virtuelle de toutes les instances de la même classe. On peut soumettre alors une opération CMIS avec une portée (scope) de niveau 1 sous l'instance qui représente la classe recherchée, sur l'objet de classe spécifique mocExtension .
Un autre avantage de cette invention est de pouvoir utiliser les index physiques qui ont été éventuellement configuré par l'utilisateur comme décrit
ci-après, pour diminuer le coût temporel de l'évaluation de l'argument CMIS filtre, lorsqu'il doit être appliqué à l'ensemble de toutes les instances d'une classe donnée. En effet, si les index sont configurés sur des attributs identifiés dans le filtre on peut les utiliser pour ne lire physiquement qu'un sous-ensemble des instances comme décrit ci-après. Il suffit simplement de reconfigurer en ligne (on-line) les index pour ne plus utiliser la partie de la clé qui mémorise la position de l'instance dans l'arbre de contenance.
Ces buts sont atteints par le fait que le service CMIS-DB définit et réalise une classe spécifique d'objet administré (MOC) appelée mocExtension . Une instance d'objet de cette classe spécifique mocExtension est automatiquement créée par CMIS-DB pour chaque classe d'objet administré que l'utilisateur déclare au service CMIS-DB. Cette déclaration permet à l'utilisateur de spécialiser par configuration, comme décrit ci-après, la structure de stockage sur disque des instances d'objet d'une classe donnée qui sinon reste générique. La représentation générique n'indexe physiquement que l'attribut obligatoire objectClass dans les fichiers ISAM de stockage de la MIB sur le disque. Alors que la spécialisation du stockage d'une MOC permet à l'utilisateur de déclarer un certain nombre de l'ensemble des attributs spécifiques de cette MOC, comme devant être indexés dans les fichiers ISAM de stockage sur le disque. La structure de ces index comporte la référence de l'objet père dans l'arbre de contenance (containement tree), mais CMIS-DB permet de ne pas inclure cette référence dans la clé de lecture physique indexée dans le cas précis où la sélection des objets sur lesquels doivent être appliquées les opérations CMIS se fait par une portée (scope) de premier niveau directement sous une instance de classe spécifique mocExtension et un filtre dont l'expression est telle que la valeur d'un ou de plusieurs attributs indexés de la MOC puisse être donnée comme clé de lecture indexée. De plus, lorsque la spécialisation du stockage d'une MOC est demandée par l'utilisateur, (par la création d'un objet de classe mocStorageConfig, voir demande de brevet N 9809825
intitulée Procédé pour l'optimisation des accès à une base de données"), CMIS-DB crée un nouveau fichier ISAM destiné à contenir toutes les instances de cette MOC et uniquement celle-ci. En conséquence, lorsque l'utilisateur veut sélectionner tout ou partie des instances de cette MOC en utilisant un argument baseObjectlnstance BOI égal à l'instance de classe spécifique mocExtension qui représente cette MOC, CMIS-DB n'accède qu'aux éléments de ce fichier et évite ainsi de visiter des noeuds de l'arbre de contenance (contaiment tree) qui ne sont pas des instances de cette MOC et qui sont par construction dans des fichiers ISAM différents.
(4). Les distances focales des différentes lentilles sont adaptées de manière à respecter les contraintes d'encombrement.
Par exemple, si le diamètre du faisceau est D1 au niveau de (5122) et doit être D2 à son arrivée sur le capteur CCD, et si la distance entre (5122) et (5174), en suivant la trajectoire prévue pour le faisceau, est L, alors si fa et fb sont respectivement les distances focales de la lentille (5125) et du doublet (5126)(5127), et compte tenu des principes exposés en 8.1.1., le critère (1) se traduit par D2= fb et le D1 fa critère (4) se traduit par 2 fa +2 fb = L , d'ou on tire fa = L 2 Dl DI + D2 et fb L 2 L)] #+# LJ2 # .